Sublime Text秒开80MB日志且内存低，VS Code因Electron框架启动慢、内存高；调试需不同配置，格式化和多光标操作逻辑各异，跨编辑器协作易因配置不互通导致断点失效。
打开80MB日志文件卡不卡？看启动耗时和内存占用
Sublime Text几乎秒开，VS Code容易卡顿——这不是配置问题，是底层框架决定的。Sublime用原生C++实现，冷启动稳定在0.4s内；VS Code基于Electron，要加载Chromium渲染进程+语言服务+扩展主机，冷启动通常1.8–2.3s。
- 实测同一台8GB内存旧笔记本：
subl access.log（80MB）耗时0.8s，滚动顺滑；code access.log耗时2.3s，首次滚动有明显延迟 - VS Code默认对>10MB文件启用
largeFileOptimizations，但语法高亮仍会拖慢渲染——别双击打开大文件，改用命令行：code --disable-extensions --disable-gpu large-file.log - Sublime Text空载内存约
90–130MB，开10个标签页+插件仍<220MB；VS Code空载就占380–460MB，开终端+Git+Python插件后常破1.1GB
调试Python或Node.js项目要不要手动配插件？
VS Code按F5→选环境就能跑，Sublime Text得自己搭LSP+debugger+解释器路径——不是不能做，而是容易漏一步就断点变灰色。
- VS Code中：
Cmd+Shift+P→Debug: Open Configuration，自动生成launch.json，自动识别venv里的python - Sublime Text需装
sublime_debugger和LSP-pyright，再手动建.sublime-debugger配置文件，并确保debugpy已安装、Python路径指向虚拟环境 - 常见错误现象：
breakpoint is disabled (gray)→ 通常是lsp_server没启动，或python路径写成系统全局路径而非./venv/bin/python
团队用.vscode/settings.json统一格式化，Sublime能读吗？
不能。VS Code的editor.formatOnSave、prettier.semi等设置，Sublime Text完全无视——除非你额外装Prettier插件，并手动把JSON字段映射过去。
- 比如VS Code里写了
"editor.tabSize": 2，Sublime需在Preferences.sublime-settings里配"tab_size": 2；字段名、嵌套层级、布尔值写法都不一样 -
settings.json支持条件配置（如"[javascript]": {"editor.formatOnSave": true}），Sublime没有等效机制，只能靠插件+作用域规则模拟，稳定性差 - 协作中真正掉队的不是“打不开”，而是
git diff里突然多出几十行格式变更——因为别人保存自动加了分号，你没配Prettier，也没开formatOnSave
想用多光标批量改行尾，哪个操作更直接？
VS Code的Shift+Alt+I一键在每行末加光标，Sublime Text得靠Ctrl+Shift+L全选再删选区——思路不同：VS Code倾向“智能预判”，Sublime倾向“选择即光标”。
- 处理
console.log(a); console.log(b);这种，想统一改成debugger;：VS Code选中所有console.log→Ctrl+Shift+L→删→输debugger;；Sublime用Ctrl+D逐个加光标，快但要看准匹配顺序 - 矩形选择（列编辑）：VS Code是
Shift+Alt+鼠标拖动；Sublime需Shift+鼠标右键拖动，部分系统右键被拦截，得改键位绑定 - Sublime响应零延迟，VS Code在插件多时（比如同时开
ESLint+Prettier+Docker）偶尔卡半拍，光标没跟上手指
真正难的不是选哪个，而是别在调试时切到Sublime改完代码又切回VS Code重载——两个编辑器的launch.json和.sublime-debugger不互通，改错一行配置，断点就失效。
