Sublime Text的Ctrl+P比VS Code更快，因其采用纯内存扫描、无预建索引，输入即匹配，延迟稳定在毫秒级；而VS Code依赖后台索引，首次触发常卡顿。
它不是“怀旧”，而是关键路径上没有妥协：启动快、搜索快、切换快、编辑快——所有快都建立在极低的资源占用上。如果你常开 20+ 标签、处理千行级配置文件、或需要秒级响应的模糊跳转，Sublime Text 仍是不可替代的。
Ctrl+P 模糊匹配为什么比 VS Code 的快速打开更轻量？
VS Code 的 Ctrl+P 依赖后台索引（尤其是大项目），首次触发可能卡顿；Sublime 的 Ctrl+P 是纯内存扫描，无预建索引，输入即匹配，延迟稳定在毫秒级。
- 适合场景：频繁在几十个临时脚本、日志片段、配置片段间跳转，不希望等“正在加载索引”
- 代价：不支持跨项目符号跳转（如函数定义），只搜文件名/路径
- 实测：在 12GB 内存的老旧笔记本上，Sublime 打开含 800 个 .py 文件的目录后，
Ctrl+P响应仍低于 80ms；VS Code 同配置下首次需 400ms+，且随插件增多递增
多光标编辑为什么比 IDE 的“列选择”更可控？
Sublime 的多光标是像素级定位，不依赖语法树或缩进逻辑——你点哪，光标就在哪，删、改、粘贴全按你指的位置来。
- 常见错误现象：
Ctrl+Click点歪了光标位置，结果批量改错行；或粘贴时因自动缩进对齐导致格式错乱 - 正确用法：先用
Ctrl+Shift+L拆分选中行 → 再Ctrl+↑/↓调整光标 → 最后统一输入；避免直接拖选+Ctrl+Click - 性能影响：100 个光标同时操作，Sublime 渲染压力远低于基于 Electron 的编辑器，不会出现输入卡顿
Package Control 插件为什么容易“越装越慢”？
不是插件本身慢，而是部分插件默认启用后台监听（如 GitGutter 每秒轮询 git status，SublimeLinter 在保存时调用外部 linter 进程）。
- 典型症状：敲击回车后延迟半秒才换行；保存文件时界面短暂冻结
- 解决办法：
Preferences → Package Settings → [插件名] → Settings – User中关闭"enable": false或设为"delay": 3000（毫秒） - 推荐精简组合：
Emmet（前端）、AutoFileName（路径补全）、BracketHighlighter（括号高亮）——这三个几乎零开销
真正被忽略的复杂点在于：Sublime 的高效不是靠功能堆砌，而是靠主动放弃。它不提供调试器、终端集成、语言服务器图形界面——这些省下来的资源，全换成了你敲下第一个字符时的那 12ms 响应。你得接受“编辑器只负责编辑”，其余交给 shell、tmux、独立 terminal 或专用工具。
