Sublime切换项目后自动保存失效,大概率是插件在on_post_save中抢控权或冲突处理所致,而非设置丢失;save_on_focus_lost本身与项目无关,其触发仅依赖窗口失焦,多窗口切换会触发,同窗tab切换则不会;常见原因包括GitGutter/LSP等插件耗时操作阻塞、项目级配置覆盖用户级设置、AutoSave与save_on_focus_lost共存导致atomic_write冲突,以及OneDrive/NAS路径下atomic_save重命名静默失败。

项目切换后自动保存失效,大概率不是设置丢了,而是插件在 on_post_save 里抢了控制权,或者多个插件对同一事件做了冲突处理。
为什么切项目后 save_on_focus_lost 看似不工作
save_on_focus_lost 本身只管“窗口失焦”,和项目无关——它触发时根本不管你在哪个项目、用了什么 .sublime-project 文件。所谓“切换项目后失效”,其实是以下情况之一:
- 你用的是多窗口模式(每个项目开一个 Sublime 窗口),从窗口 A 切到窗口 B 属于“失焦”,
save_on_focus_lost会正常触发;但如果你只是在同一个窗口里点不同 tab 或切换 project sidebar,这不算失焦,不会保存 - 某个插件(如 GitGutter、LSP、SublimeLinter)注册了
on_post_save,并在里面执行耗时操作(比如调用外部进程、遍历整个项目目录),导致保存流程卡住,看起来像“没保存” - 项目级设置(
.sublime-project)里误写了"save_on_focus_lost": false,它会覆盖用户级设置,且优先级更高 - AutoSave 插件被启用,同时又开了
save_on_focus_lost,两者都试图保存,结果因 atomic_write 冲突或重命名失败导致静默失败
如何快速定位是哪个插件在 onSave 里拖后腿
别靠猜,直接看控制台实时日志:
- 按
Ctrl + `打开控制台,右键 → Clear Console 清空 - 改一行代码,然后手动按
Ctrl + S保存 - 盯住控制台顶部新输出的几行:如果看到类似
running GitGutter.on_post_save或LSP: sending textDocument/didSave后卡顿 2–3 秒,就锁定它 - 特别注意带毫秒数的日志,例如
SublimeLinter: linter 'eslint' took 2841ms—— 这说明 ESLint 插件在保存后强行跑了一次检查 - 如果控制台刷出
plugin_host has exited unexpectedly,紧接着几秒无输出,基本是某插件崩溃后阻塞了后续事件链
插件优先级与配置冲突怎么解
Sublime 的事件响应没有显式优先级队列,但行为上存在隐性顺序:原生逻辑最先执行,然后是插件按加载顺序依次回调。问题常出在“谁先改了文件状态”或“谁把 rename 搞崩了”:
-
save_on_focus_lost和 AutoSave 插件的auto_save_on_focus_lost必须二选一,同时开会导致重复 write + rename,尤其在 NAS / OneDrive / Dropbox 路径下极易失败 - GitGutter 默认每保存一次就刷新状态,如果项目含大量文件,
git status调用会拖慢整个保存流程;可临时在项目设置里加"git_gutter_enable": false验证 - LSP 插件若配置了
"auto_reload": true或启用了 heavy language server(如 rust-analyzer),on_post_save可能触发 full re-index,必须关掉或设为false - 删插件不能只删
Packages/XXX目录——Sublime 仍会从Installed Packages/XXX.sublime-package加载;正确方式是 Preferences → Package Control → Disable Package,再彻底退出进程验证
atomic_save 导致的“假失效”最容易被忽略
Sublime 默认开启 atomic_save:先写 file.tmp,再 rename 成原文件。这个 rename 在某些环境会静默失败:
- OneDrive / Dropbox 正在同步中,文件被锁,
rename返回Permission denied,但 Sublime 不报错,也不回退到直接 write - NAS 或 SMB 共享路径不支持原子重命名,导致 tmp 文件残留,原文件时间戳不变,看起来像没保存
- 解决方法不是关
atomic_save(不推荐),而是临时关掉云同步工具,或改用save_on_focus_lost+ 手动 Ctrl+S 组合策略 - 验证是否是这个问题:改完内容后切出窗口 → 立刻进终端执行
ls -la | grep "\.tmp$",如果看到未清理的 tmp 文件,就是 atomic_save 失败了

















