atomic_save仅防写入中断导致文件损坏，不防误删或误改；它通过先写临时文件再原子重命名实现，无法关闭，但可能因外部占用、符号链接、错误脚本或云同步冲突而失效。
Sublime Text 默认就开启 atomic_save，根本不用手动开——但很多人误以为它能防覆盖、防误删，其实它只管“写入不中断”这一件事。
atomic_save 是什么，它到底防什么
atomic_save 不是备份，也不是版本控制，它的唯一作用是：当 Sublime 向磁盘写入文件时，先写到一个临时文件（比如 .filename.tmp），写完再原子性地重命名为原文件名。这样哪怕写到一半崩溃、断电或磁盘满，原文件也不会被截断或损坏，旧内容完整保留。
它防的是「保存中途出事导致文件变半截」，不防「你手抖删错一行后点了保存」，也不防「改完忘 git commit，关机后发现没备份」。
- 该机制由 Sublime 内核强制启用，无法关闭
- 只对正常保存（
Ctrl+S或Cmd+S）生效，不适用于「Save Copy As」或插件钩子触发的复制命令 - 在 NFS、SMB 等网络文件系统上可能失效（因 rename 不保证原子性）
为什么你还是遇到“保存后文件变空”或“内容错乱”
这不是 atomic_save 失效，而是其他环节出了问题：
- 文件被外部程序占用（如正在被
tail -f读取、被 Python 脚本以r+模式打开），Sublime 保存时可能写入失败但 UI 没报错 - 编辑的是符号链接，而 atomic_save 对目标文件操作，链接本身没更新（表现为“看起来没保存”）
- 用了错误的
auto_save_hook，比如 Windows 下写成copy '$file' '$file.bak'（单引号在 cmd 里无效），结果命令静默失败，你以为存了其实没存 - 启用了
hot_exit: false+ 关闭前没手动保存，崩溃后连未保存内容都丢了——atomic_save 根本没机会运行
想真正避免文件损坏，得组合用这几个配置
atomic_save 只是底层保障，上层还得靠人设防：
- 务必打开
"hot_exit": true和"remember_open_files": true：它们让 Sublime 在异常退出后能恢复所有未保存修改，比依赖每次保存更可靠 - 敏感文件（如
nginx.conf、.env）禁用自动保存，改完手动Ctrl+S+ 右键侧边栏 →Save Copy As手动打时间戳快照 - 避免在云同步目录（OneDrive、iCloud Drive）直接编辑大文件，同步进程可能和 atomic_save 的 rename 冲突
- Linux/macOS 下如果编辑挂载的远程文件系统，确认
mount选项含noatime和sync，否则 atomic_save 的临时文件可能落盘延迟
atomic_save 很安静，从不弹提示，也从不生成日志。它只在你最不需要它的时候默默起作用——比如突然断电。但凡你看到文件损坏，问题一定出在它之外。
