sublime text大文件编辑不卡顿的关键在于其c++原生实现、仅行级渲染与正则高亮、依赖mmap内存映射加载，且不启用lsp、语法分析或文件监视，避免后台重排与语义索引开销。
Sublime Text 不是 VS Code 的轻量替代品，而是解决另一类问题的工具——它在「打开就用、改完就关」的场景里几乎不会让你等它。
大文件编辑不卡顿的关键在哪
Sublime Text 用 C++ 写核心，不解析 AST，不做后台语言服务（LSP），只做行级渲染和正则高亮。这意味着打开一个 400MB 的 app.log 或嵌套 20 层的 nginx.conf，它靠内存映射（mmap）加载，滚动、搜索、替换基本无延迟。
- VS Code 默认启用 LSP 和文件监视器，大文件会触发语法分析、Git 状态扫描、语义索引，容易卡顿甚至崩溃
- Sublime 的
view.settings().set("word_wrap", false)可强制关闭换行，避免长日志行二次渲染开销 - 别指望它实时 tail —— 它不监听文件变化，
Ctrl+R手动重载才是它的哲学
启动快、内存低不是营销话术
实测 Sublime Text 4 在 macOS M2 上冷启动耗时
- 资源敏感场景（如老旧笔记本、Docker 容器内编辑、CI 临时调试）优先选 Sublime
- 它没有内置终端、调试器、Git UI，这些不是“缺失”，而是主动剥离——你不需要为不用的功能付费（CPU/内存）
- 插件如
SideBarEnhancements或AdvancedNewFile是 Python 写的，加载慢一点但不影响主进程响应
高频小任务下的操作流更干净
当你每天要重复「查配置 → 改一行 → 保存 → 退出」这类动作上百次，Sublime 的命令面板（Cmd+Shift+P）模糊匹配、多光标批量改名、Ctrl+D 逐词选中、Ctrl+Shift+K 删除整行，全是原生实现、无 JS 引擎调度延迟。
- VS Code 的快捷键可能被扩展、键盘布局、远程连接层多次拦截，尤其在 WSL 或 SSH 连接下有明显输入滞后
- Sublime 的
find_in_files直接调用系统grep（Linux/macOS）或findstr（Windows），比 VS Code 的搜索慢一点但更稳，不崩、不假死 - 它不记录最近打开的项目列表，
Ctrl+P模糊搜索只扫当前工作区，隐私和速度兼顾
插件生态萎缩但够用，关键是别乱装
Package Control 上活跃插件只剩约 300 个，但覆盖了绝大多数文本处理刚需：比如 GitGutter 显示行级变更、EditorConfig 统一缩进、SublimeLinter 接 pylint 或 eslint，都不依赖 Node.js 运行时。
- 别装需要后台服务的插件（如旧版
SublimeCodeIntel），它们已停止维护，且和 ST4 不兼容 -
Emmet在 HTML/CSS 中依然高效，但别指望它支持 Vue SFC 或 JSX——那是 VS Code 的战场 - 所有插件配置都落在
Preferences.sublime-settings或插件专属的.sublime-settings文件里，改错一个括号就整个插件失效，记得备份
真正容易被忽略的点是：Sublime 不适合「边写边调」，也不适合「多人共用同一套开发环境」。它假设你清楚自己在改什么、改完立刻交给其他工具验证——比如用 temporal cli 提交 workflow，而不是在编辑器里点个按钮就跑起来。这种克制，恰恰是它至今没被淘汰的原因。
