根本原因是Sublime Text默认将文件当代码处理，语法高亮、索引、插件扫描等后台任务持续占用内存；关index_files、设Plain Text、清Cache/Index/Local三目录并禁用GitGutter/LSP等插件可立解。
为什么 Sublime Text 会突然吃掉 2GB 内存并卡死？
根本原因不是软件本身“变慢”，而是它在后台持续缓存未关闭的文件内容、语法高亮状态、插件运行上下文，尤其当打开过大型日志、JSON、minified JS 或含超长行的文件后，sublime_text.exe（Windows）或 Sublime Text 进程会把整行文本当作单个 token 加载进内存——哪怕只是用 Ctrl+Shift+P 调出命令面板时临时解析一次。
常见触发场景包括：
- 同时打开 >50 个标签页，其中混有 >10MB 的文本文件
- 安装了未做内存限制的插件，比如
GitGutter在大仓库中频繁调用git status - 启用了
highlight_line+draw_white_space+word_wrap三重渲染叠加 - 使用了自定义
color_scheme中含大量正则匹配规则的.tmTheme文件
关闭自动索引与项目缓存能立刻释放 30%–60% 内存
Sublime Text 默认为每个打开的文件夹启用递归文件索引（用于 Goto Anything 和符号跳转），但多数前端/脚本项目并不需要全量索引。禁用后不仅内存下降明显，首次启动速度也会加快。
操作路径：Preferences → Settings – Project，在右侧 JSON 中添加：
{
"index_files": false,
"folder_exclude_patterns": ["node_modules", ".git", "__pycache__"],
"file_exclude_patterns": ["*.log", "*.min.js", "*.zip"]
}
注意：index_files 设为 false 后，Ctrl+P 将无法搜索未打开文件的内容（仅支持已打开文件名和符号），但可避免后台扫描卡住 UI 线程。
插件是内存泄漏主因，必须按需启用
不是所有插件都遵循 Sublime 的 API 生命周期管理。尤其以下几类插件极易累积引用、不释放 buffer：
-
SideBarEnhancements：在右键菜单中预生成大量 DOM 节点，打开深层嵌套目录时触发 -
EmberHelper或Vue Syntax Highlight：对非 .vue 文件误触发解析器初始化 -
SublimeLinter+eslint：每次保存都 spawn 新进程且不回收 stdout 缓冲区
建议做法：
- 用
Package Control: Disable Package逐个禁用，观察任务管理器中内存变化 - 将
SublimeLinter改为仅在保存时 lint："lint_mode": "save"，而非"background" - 删除
~/.config/sublime-text-3/Packages/User/下残留的旧插件配置文件（如Emmet.sublime-settings已卸载但仍存在）
编辑大文件前必须手动切换到「只读 + 无语法」模式
打开一个 200MB 的 access.log 时，如果 Sublime 按默认方式加载，会尝试构建整棵树状语法结构，并为每行计算折叠区域、括号匹配、颜色 token——这直接导致 UI 冻结 10 秒以上且无法中断。
正确姿势：
- 先用
File → Open打开文件，不要双击 - 打开后立即执行
View → Syntax → Plain Text（绕过任何 .sublime-syntax 解析） - 再执行
View → Read Only（禁用 undo stack 和 dirty 标记） - 最后关闭所有辅助渲染：
View → Hide White Space、View → Hide Minimap、View → Hide Sidebar
这样处理后，同个文件内存占用通常从 1.8GB 压缩到 200MB 左右，滚动和搜索基本不卡。
真正棘手的是那些被插件悄悄 hook 的场景——比如某个主题强制重绘状态栏，而你根本没注意到它正在为每一行重新计算宽度。这类问题不会报错，只会让内存缓慢爬升，直到某次 Ctrl+Z 触发 undo 栈重建才彻底卡死。留心 Ctrl+Shift+P 输入 Profile 调出性能分析器，看哪个 plugin 的 on_modified_async 回调耗时异常高。
