关闭 Sublime 的 atomic_save 机制需在 Preferences → Settings – User 中添加 { "atomic_save": false }；同时设 { "backup_before_save": false } 可禁用 .sublime-backup 文件，二者独立生效。
如何关闭 Sublime 的 atomic_save 机制
Sublime 默认开启 atomic_save，它不直接覆盖原文件，而是先写入临时文件再重命名。这个过程在磁盘满、杀软拦截或临时目录不可写时会静默失败——你 Ctrl+S 没反应，文件状态栏仍显示 “modified”，但磁盘时间戳不变。这不是 bug，是设计行为。
关闭它的方法很简单：打开 Preferences → Settings – User，在 JSON 中添加：
{
"atomic_save": false
}
注意：atomic_save 是全局设置，无法按项目单独关闭；改完保存即生效，无需重启。
- 关掉后，Sublime 会直接覆写原文件，写入失败时会弹出明确错误（如 “Permission denied”），便于快速定位问题
- 某些企业环境禁用重命名操作（如 NFS 挂载卷），必须关掉
atomic_save才能保存 - 不建议长期关闭——它本意是防止写入中断导致文件损坏；仅在确认路径稳定、权限无误时临时禁用
禁用自动备份文件（.sublime-backup）
Sublime 不生成传统意义上的 “~” 或 “.bak” 备份，但它会在修改未保存前，把原始内容悄悄存为 .sublime-backup 文件（同名，后缀不同）。这些文件默认出现在原文件同一目录下，容易被 Git 误提交或干扰清理脚本。
真正控制它的参数是 backup_before_save，不是 create_backup_copy（后者早已废弃且无效）：
{
"backup_before_save": false
}
该设置同样写在 Preferences → Settings – User 中。设为 false 后，Sublime 不再生成任何 .sublime-backup 文件。
-
backup_before_save是唯一有效开关；设成true时，每次保存都会生成一个备份（哪怕只改了一个字符） - 备份文件没有自动清理机制，积多了会占空间；关掉后也省去手动
find . -name "*.sublime-backup" -delete - 若你依赖备份做后悔药，建议改用 Git 提交历史或 Time Machine / Windows File History 等系统级方案，更可靠
为什么 ignore_package 和 disabled_packages 对备份无效
有人试图通过禁用某个插件来阻止备份，比如在 ignored_packages 里加 "Backup" 或 "AutoSave"，结果发现完全没用——因为 .sublime-backup 是 Sublime 内核级行为，和插件无关。
所有与保存、备份、原子写入相关的逻辑都硬编码在编辑器主进程中，不受 Package Control 管理。你看到的 “AutoSave” 插件只是定时触发 save 命令，它不参与文件落盘环节。
-
ignored_packages只影响插件加载，对内核功能零干预 - 想绕过备份？别动插件配置，只改
backup_before_save和atomic_save - 某些第三方插件（如 SyncedSidebar）可能自己生成临时文件，那得单独查它的文档，不是 Sublime 本身的备份
临时文件残留的真正来源
除了 .sublime-backup，你可能还看到 sublime-XXXX.tmp 或 subl_XXXX.tmp 文件。它们通常不是 Sublime 主动创建的，而是：
- 杀毒软件（尤其是 Windows Defender “受控文件夹访问”）拦截重命名后遗留的临时文件
- 磁盘空间不足时，
atomic_save写临时文件失败但没清理干净 - 崩溃退出后未完成的写入流程残留（这时删掉即可，不影响后续使用）
这类文件无法通过配置禁止，只能从源头解决：关掉 atomic_save + 关闭实时防护 + 确保磁盘有足够空间（至少 100MB）。一旦出现残留，手动删除无害，Sublime 不会读取或恢复它们。
最常被忽略的是：atomic_save 和 backup_before_save 是两个独立开关，必须同时关才真正“不存任何额外副本”。只关一个，另一类临时文件照旧生成。
