Sublime Text更适合轻量高频文本处理，VS Code更适合现代项目开发；前者启动快、内存低、大文件流畅，后者功能全、调试强、生态广但资源占用高。
没有“更适合”的编辑器，只有你此刻要打开的文件、手边的机器、正在执行的动作是否匹配它的设计哲学。
打开 400MB 的 access.log 时卡不卡
Sublime Text 用 mmap 直接内存映射加载，滚动、搜索、正则替换基本无延迟；VS Code 默认启用 LSP、Git 监视、语义索引，大文件容易假死或崩溃。
- VS Code 可临时绕过：终端执行
code --disable-extensions --disable-gpu large-file.log - Sublime 不自动重载：文件被外部程序修改后，需手动按
Ctrl+R刷新，不是 bug 是设计选择 - 别开 Sublime 的
word_wrap（设为false），长日志行二次渲染会拖慢响应
调试 Python 或 Node.js 时断点能不能停住
VS Code 按 F5 → 选环境 → 自动生成 launch.json，自动识别 venv 路径；Sublime 需手动配 sublime_debugger + LSP-pyright + debugpy，漏一步断点就变灰色。
- 常见错误现象：
breakpoint is disabled (gray)→ 检查python.path是否指向./venv/bin/python，而非系统全局路径 - Sublime 的调试本质是包装外部命令，无法读闭包、改变量值、中断执行流
- VS Code 的调试器是进程级集成，但插件一多（ESLint + Prettier + Docker）CPU 容易飙到 70%+
团队共享 .vscode/settings.json 时 Sublime 能不能同步格式化规则
不能。VS Code 的 editor.formatOnSave、prettier.semi 等字段 Sublime 完全无视——除非你额外装 Prettier 插件，并手动把 JSON 字段映射成 Preferences.sublime-settings 里的 tab_size、translate_tabs_to_spaces 等。
-
.vscode/settings.json支持条件配置（如"[javascript]": {"editor.formatOnSave": true}），Sublime 没等效机制 - 真正掉队的不是打不开项目，而是别人保存后自动加了分号、删了空行，你没配格式化，
git diff里突然冒出几十行无关变更 - 解法是把规则抽成跨编辑器可读的文件：
.prettierrc、.eslintrc.cjs，但 Sublime 需确认 LSP 插件已启用对应语言服务器
每天改一百次 .env 或 nginx.conf 哪个更跟手
Sublime 的 Ctrl+P 是纯本地索引，模糊搜索快；VS Code 的 Cmd+P 首次常触发后台扫描，尤其在未配 files.watcherExclude 的大项目里可能卡顿半秒以上。
- Sublime 多光标：
Ctrl+D逐词选中，Ctrl+Shift+K删除整行，全是原生 C++ 实现，无 JS 调度延迟 - VS Code 快捷键可能被扩展、SSH 层、键盘布局多次拦截，在 WSL 或远程连接下输入滞后明显
- Sublime 不记录最近项目列表，隐私和速度兼顾；VS Code 默认全扫子目录，
search.exclude配错会导致 CPU 持续 30%+
最易被忽略的不是功能多寡，而是你每次按下快捷键后，到底是在等编辑器，还是编辑器在等你——前者消耗的是注意力碎片，后者消耗的是调试时间。选错不会报错，但会持续拖慢节奏。
