sublime中ctrl+s无反应是因atomic_save或encoding导致静默失败：前者在写.tmp再rename时被onedrive/nas/杀软拦截，后者因编码不匹配触发系统写保护；两者均不报错。
为什么Ctrl+S后没反应也不报错
这是最典型的“偶发性无响应”：文件状态栏仍显示modified，磁盘时间戳不变，控制台Ctrl+`里空空如也。根本不是卡死，而是保存流程被静默中断——atomic_save写临时文件失败，或save_on_focus_lost被插件阻塞，两者都不抛异常。
atomic_save导致的静默失败怎么验证
默认开启的atomic_save会让Sublime先写.sublXXXX.tmp再重命名，一旦失败就彻底沉默。常见拦截点包括OneDrive“按需同步”目录、WSL2的/mnt/c/路径、NAS挂载点、杀毒软件实时防护。
- 打开控制台
Ctrl+`，执行view.window().active_view().file_name()复制路径 - 在终端手动测试重命名：
touch test.tmp && mv test.tmp test.txt（Linux/macOS）或echo. > test.tmp && ren test.tmp test.txt（Windows） - 如果报错“Permission denied”或“No such file or directory”，说明rename被拦，不是Sublime的问题
- 临时验证：在
Preferences → Settings – User中加"atomic_save": false，再试保存
save_on_focus_lost和插件钩子如何互相拖垮
save_on_focus_lost本身不卡，但它会同步等待所有插件的保存钩子完成。GitGutter轮询git状态、LSP触发诊断、AutoSave重复触发——这些全在主线程堵着，光标延迟300ms以上是常态，尤其在OneDrive同步目录或远程文件系统上。
- 禁用
save_on_focus_lost：设置里删掉或设为false - 关GitGutter的同步行为：
Preferences → Package Settings → GitGutter → Settings – User中写{"non_blocking": true} - LSP插件调高延迟：
"diagnostics_delay_ms": 2000（别设0） - 确认没装AutoSave插件——它和
save_on_focus_lost共存等于双倍I/O
encoding不匹配也会触发系统级写保护
文件实际是UTF-8 with BOM，但Sublime以UTF-8（无BOM）读取并保存，Windows部分应用会拦截这种编码“不一致”的写入，表现就是Ctrl+S后内容没更新，连控制台都安静。
- 控制台执行
view.encoding()，返回Western (Windows 1252)或undefined就危险 - 立刻菜单→
File → Save with Encoding → UTF-8（不是UTF-8 with BOM） - 对中文/日文项目，建议统一设为
UTF-8，避免BOM引发的跨平台解析歧义 - 如果必须保留BOM，用
Save with Encoding → UTF-8 with BOM，但要确保所有协作方工具兼容
真正难缠的是atomic_save和encoding问题——它们不报错、不弹窗、不记日志，只让保存变成一场无声的失效。调试时关掉atomic_save是最快验证手段，但长期关闭有风险；而encoding错配则需要你主动检查，而不是等错误发生。
