save_on_focus_lost 是 Sublime Text 唯一安全低开销的原生自动保存机制，仅在窗口失焦时对已修改可写文件执行一次写入，不轮询、不监听、不计时；新建未命名、只读或权限受限文件被跳过；auto_save 等字段无效且可能破坏设置；需空闲保存必须用 AutoSave 插件并正确配置。
save_on_focus_lost 是唯一安全、低开销的原生方案
Sublime Text 没有“实时保存”或“修改即存”的原生能力，save_on_focus_lost 是唯一真正生效、零额外开销、不卡 UI 的自动保存机制。它只在你切出整个 Sublime 窗口（比如点到终端、浏览器、桌面）时，对已修改且可写的文件执行一次 write() 调用——不轮询、不监听输入、不计时，自然不消耗 CPU 或触发频繁磁盘 I/O。
- 新建未命名文件（
untitled）不会保存，这是设计，不是 bug - 只读文件、权限受限路径（如
/etc/hosts或挂载的网络盘）会被跳过，Sublime 不报错也不重试 - 仅切换 tab、打开命令面板（
Ctrl+Shift+P）、甚至多窗口模式下从 A 窗口切到 B 窗口（同进程），都算“失焦”，会触发；但仅在单个窗口内切 tab 不会
别写 auto_save、auto_save_interval 这类无效字段
这些键名在 Sublime 官方源码和文档中根本不存在。你在 Preferences → Settings – User 里写上 "auto_save": true、"auto_save_interval": 60 或 "save_on_modified": true，Sublime 解析器会静默忽略——既不报错，也不生效，还可能埋雷：
- 一个错位逗号或漏闭引号，会导致整个用户设置加载失败，连
save_on_focus_lost都失效 - 某些版本的 AutoSave 插件会误读这些字段，以为“原生已启用”，从而禁用自己的核心逻辑，结果是自动保存彻底失灵
-
save_on_modified自 ST4100 起已完全移除支持，写进去等于白写，且容易干扰 LSP 插件（如LSP-pyright）的自身保存判断
需要空闲保存？必须用 AutoSave 插件，且配置入口不能错
如果你真要“打字停顿 2 秒就保存”，就得换方案：卸载 save_on_focus_lost，装 AutoSave 插件（作者 randy3k，v4.1+），并严格写在它的专属配置里：
- 先在
Preferences → Settings – User中删掉或注释掉"save_on_focus_lost": true - 按
Ctrl+Shift+P→ 输入Package Control: Install Package→ 安装AutoSave - 进
Preferences → Package Settings → AutoSave → Settings – User（不是通用 Settings！） - 最小可用配置只有两个字段：
"auto_save_on_idle": true和"auto_save_delay_milliseconds": 3000 -
auto_save_delay_milliseconds别设太小：500 会导致边打字边保存，UI 卡顿；对 >5MB 的日志或 SQL 文件，建议 ≥3000
两个机制混用会引发 I/O 冲突
同时开启 save_on_focus_lost 和 AutoSave 的 auto_save_on_idle（或插件自带的 auto_save_on_focus_lost），会导致同一文件在失焦瞬间被保存两次。这不是“更保险”，而是：
- 小文件可能无感，但大文件（如几百 MB 的日志）会明显卡顿，甚至触发系统级文件锁
- 若外部进程（如
tail -f、数据库导入脚本）正在读取该文件，重复写盘可能造成内容错乱或读取中断 - 插件配置项名称混乱（
auto_save_delay_in_ms、auto_save_delay_in_seconds等）在 v4.1+ 中已全部失效，只认auto_save_delay_milliseconds
性能优化的关键，从来不是“多加一层保存”，而是选对触发时机、避开冲突路径、尊重文件状态——比如未命名、只读、大体积，这些条件不满足时，强行保存毫无意义。
