保存卡顿主因是插件在on_post_save中执行耗时操作，如调用lsp、遍历项目或同步git；应通过控制台日志定位插件，用package control禁用并彻底重启验证，同时调整gitgutter和lsp配置降低负载。
保存文件卡三秒，基本就是插件在 on_post_save 里干了重活
不是磁盘慢，也不是文件大——是某个插件注册了 on_post_save 事件，每次保存后强行执行耗时操作：比如调用外部 LSP server、遍历整个项目找 import、或同步 Git 状态。这类卡顿不会报错，但控制台（Ctrl + `）里能看到明显延迟日志，比如 plugin_host has exited unexpectedly 后紧跟着几秒空白，或者反复刷 running <plugin_name> on_post_save</plugin_name>。
怎么快速锁定是哪个插件在 onSave 里拖后腿
别猜，直接看控制台实时输出：
- 保存前先打开控制台（
Ctrl + `），清空它（右键 → Clear Console） - 立刻保存一个普通文件（比如
test.js），盯住控制台最顶上 2–3 行新输出 - 如果看到
File "./Packages/XXX/xxx.py", line XX, in on_post_save→ 记下XXX，八成就是它 - 如果看到
SublimeLinter: linter 'eslint' took 2841ms这类带毫秒数的耗时提示，对应插件名直接暴露 - 没有堆栈但有大量
GitGutter: updating status或LSP: sending textDocument/didSave日志 → 检查 GitGutter、sublime-lsp 等后台活跃插件
禁用插件必须重启，且不能靠删文件夹
手动删 Packages/SomePlugin 文件夹无效：Sublime 仍会从 Installed Packages/SomePlugin.sublime-package 加载。正确流程是：
- 进
Preferences → Package Control → Disable Package，选中疑似插件名（注意大小写，emmet和Emmet是两个东西） - 必须彻底退出 Sublime（Windows 查任务管理器确认
sublime_text.exe进程消失；macOS 用活动监视器查） - 再启动，测试保存是否还卡
- 如果禁用 A 后卡顿变轻但没消失，说明存在依赖链：A 插件调用了 B 插件的函数，B 崩溃导致 A 报
NoneType is not callable，得从底层插件开始禁
关掉 index_files 能砍掉一半卡点，但别只改用户设置
"index_files": false 必须加在用户设置里，且要彻底重启才生效。但它只是止血，不是根治——有些插件（如 GitGutter、LSP）根本不走索引，而是自己轮询或 fork 进程。真正要动的是：
- GitGutter 设置里加
"non_blocking": true, "live_mode": false，让它不抢主线程 - LSP 插件配置中限制作用范围：
"enabled": false全局关，再在项目里按需开 - 删掉用户目录下顽固缓存：
%userprofile%\.codeintel（Windows）、~/.cache/sublime-text/（Linux/macOS） - 检查杀毒软件是否把
sublime_text.exe当可疑进程拦截——尤其 Windows Defender 在保存瞬间扫描文件时会锁死 IO
真正麻烦的不是找到那个插件，而是它背后可能连着一套自动同步逻辑或远程诊断服务；禁用后记得检查项目级配置（.sublime-project）里有没有硬编码启用它的开关，否则重启就复活。
