sublime保存卡顿主因是atomic_save同步写盘与插件保存钩子（如gitgutter轮询、lsp分析）双重阻塞；应禁用atomic_save、关闭gitgutter或设为non_blocking、调高lsp诊断延迟，并对大文件切plain text模式。
Sublime 保存卡顿，八成不是磁盘慢，而是它在“同步写盘”+“等插件响应”——比如 GitGutter 每次保存都要轮询状态，LSP 插件顺手触发一次分析，save_on_focus_lost 还没执行完，光标就卡住半秒。真要解决，得绕过这些阻塞点。
为什么 save_on_focus_lost 会卡住光标
这个原生选项看似安全，实则暗藏同步陷阱：它在窗口失焦瞬间触发保存，但 Sublime 不会排队或降级处理——如果此时 GitGutter 正在调用 git status，或 LSP 在后台解析刚改的 TypeScript 文件，主线程就会被拖住。你切到终端再切回来，光标可能延迟 300~800ms 才响应。
- 只对已修改文件生效，但不控制插件行为
- Windows 下搭配网络盘或 OneDrive 同步目录时，卡顿更明显（
save_on_focus_lost等 I/O 完成才放行） - 和
atomic_save冲突：后者默认开启，要求先写临时文件再原子替换，加重磁盘压力
禁用 atomic_save + 关掉插件监听才是关键
真正起效的组合不是“加什么”，而是“砍掉什么”。atomic_save 和插件的保存钩子（save hooks）才是同步阻塞的双引擎。
- 在
Preferences → Settings – User中添加："atomic_save": false - 进
Preferences → Package Settings → GitGutter → Settings – User，写入：{"enable_git_gutter": false}或{"non_blocking": true} - 对 LSP 插件（如
LSP-pyright），进其设置关掉"auto_complete": false和"diagnostics_delay_ms": 2000（别设为 0） - 确认没启用
AutoSave插件——它和save_on_focus_lost共存会重复保存，I/O 翻倍
大文件保存必须切 Plain Text 模式
超过 5MB 的日志、JSON 或 SQL 文件，语法高亮器会在保存前重绘整页，尤其 .vue 或带内联 <script></script> 的 HTML 文件，正则解析直接吃满单核。这不是配置问题，是渲染路径本身不可跳过。
- 右下角点击当前语法名（如
Vue Component），选Open all with current extension as… → Plain Text - 或快捷键
Ctrl+Shift+P→ 输入Set Syntax: Plain Text - 对特定后缀强制生效：在
Preferences → Settings – Syntax Specific（确保当前是目标文件）中加："syntax": "Packages/Text/Plain text.tmLanguage"
最常被忽略的是：即使关了 index_files、清了 Index 目录，只要没杀干净 sublime_text.exe 进程，旧索引线程仍在后台跑；而 save_on_focus_lost 卡顿，90% 都发生在你没动过设置、只是多开了一个含 node_modules 的项目之后——因为插件默认监听整个项目路径，不是当前文件。
