sublime Text 的高效源于极简设计：启动、搜索、切换、编辑均快速且低资源占用；Ctrl+P 无索引实时模糊匹配；多光标编辑精准可控；插件惰性加载；跨平台行为一致；轻量需主动精简插件。
sublime text 至今仍是许多程序员的首选，不是因为它“新”，而是因为它在关键操作路径上几乎没有冗余耗时——启动快、搜索快、切换快、编辑快，且所有这些快都建立在极低的系统资源占用之上。
为什么 Ctrl+P 比 ide 的“Open File”快一个数量级？
因为 Ctrl+P（goto Anything）不依赖后台索引服务，它直接扫描当前项目文件名（可配置忽略 .git、node_modules 等），用模糊匹配算法实时响应。实测打开含 3200 个文件的 c++ 项目，首次输入即出结果，无卡顿。
- 默认会扫描所有子目录，但可通过
"folder_exclude_patterns": ["build", "__pycache__"]在Preferences → Settings中加速 - 不支持语义搜索（如“找所有叫
init_db的函数”），只搜文件名/符号名/行号，这反而是它轻量的原因 - 若误触发了慢速搜索（比如输错太多字符导致回溯），按
Esc可立即中断，IDE 的类似面板常需等待动画收起
多光标编辑为什么比正则替换更安全高效？
当你需要改 8 处 user_id 为 uid，但其中 2 处在注释里、1 处是 user_id_str 的一部分——Alt+F3（全选相同词）或 Ctrl+D（逐个加选）能让你肉眼确认每一处，而正则一不小心就批量污染。
-
Ctrl+Click：鼠标点哪光标加在哪，适合非规律位置（如 jsON 的多个 key） -
Ctrl+Shift+L：把每行选中内容拆成独立光标，适合对齐修改（如给 10 行 sql 都加WHERE 1=1） - 危险点：
Ctrl+D连续按太快可能跳过中间匹配项；建议按一次后停顿半秒再按，或改用Ctrl+K, Ctrl+D（跳过当前匹配）
插件为何不拖慢启动速度？
Sublime 的插件是惰性加载的：没调用就几乎不占内存。比如 GitGutter 只在打开 Git 仓库里的文件时才初始化，SublimeLinter 仅在保存或聚焦时触发检查。
- 真正影响速度的是“自动激活”的插件，例如某些 LSP 客户端会在打开任意
.py文件时立刻拉起pylsp进程 - 验证方法：打开
console（Ctrl+`），输入sublime.log_commands(True)，再操作，看哪些命令耗时长 - 禁用插件不等于卸载：
Preferences → Package Control → Disable Package，比删文件夹更安全
跨平台一致性到底稳在哪里？
不是“都能装”，而是键位逻辑、文件编码处理、换行符行为、甚至 Ctrl+Shift+P 命令面板的过滤策略，在 windows/macOS/linux 上完全一致。连 SideBarEnhancements 右键菜单里“Open in Terminal”在各平台调用的命令都自动适配（Windows 用 PowerShell，macOS 用 zsh，Linux 用 bash）。
- 唯一常见差异：macos 的
Cmd键在快捷键文档里统一写作Ctrl，实际使用时需 mentally swap（这点官方从 ST3 就坚持，反而减少记忆负担） - 不兼容点：某些依赖 GUI 库的插件（如图形化调试器）在 headless Linux 服务器上无法启用，但核心编辑功能照常
真正的复杂点不在功能多寡，而在于——你得主动关掉那些“看起来有用但其实不用”的插件。很多人装了 20 个插件，却只用 Ctrl+P 和 Ctrl+Shift+P，其余都在后台悄悄吃内存。轻量不是默认状态，是持续修剪的结果。