sublime保存时“锁死”却无报错，是因为atomic_save的rename操作被系统或中间层（如wsl2/mnt/c、onedrive按需同步目录、nas/smb卷、加密容器）静默拦截，导致写入失败但不报错。
为什么保存时“锁死”却无报错？
Sublime Text 按下 Ctrl+S 后界面卡住、状态栏仍显示 “modified”、磁盘时间戳不变——这不是编辑器卡死，而是写入流程被系统或中间层拦截后静默失败。根本原因不是 Sublime 本身，而是它依赖的底层文件操作（尤其是 atomic_save 的 rename）在某些硬盘/文件系统路径上被硬性阻断。
哪些路径会触发硬盘级写入锁死？
以下场景中，Windows 或 Linux 内核、云同步服务、虚拟化层会主动拒绝 rename 系统调用，导致 Sublime 无法完成原子保存：
-
WSL2中访问/mnt/c/下的路径：Windows 文件系统驱动对跨子系统重命名有严格限制，常返回EPERM但不透出错误 - OneDrive / Dropbox / iCloud “按需同步”开启的目录：文件实际未完全落地，
rename被同步客户端拦截，Sublime 控制台无日志 - NAS 或 SMB 网络挂载卷：部分 NAS 固件不支持原子替换，或权限模型不兼容
rename - 加密容器（如 VeraCrypt 卷）、只读挂载的 ext4 分区：内核直接拒绝写操作，Sublime 不会弹窗提示
怎么快速验证是不是硬盘写入限制？
别猜路径，直接用终端复现 Sublime 的保存行为：
- 复制当前文件路径：
view.window().active_view().file_name()（在 Sublime 控制台Ctrl+`中执行） - 在终端中模拟原子保存：
cp your_file.txt your_file.txt.tmp && mv your_file.txt.tmp your_file.txt
如果这步报Permission denied或卡住，就是硬盘/文件系统层锁死 - 对比测试：
cp your_file.txt ~/Desktop/test_copy.txt—— 若能成功，说明问题锁定在原路径
绕过硬盘写入限制的实操方案
禁用 atomic_save 是最快生效的调试手段，但它只是绕过 rename，不解决根本权限问题：
- 临时关闭：打开
Preferences → Settings，在右侧用户设置中添加："atomic_save": false
保存后立即生效，Sublime 改为直接覆写原文件（风险：断电可能丢数据） - 更安全的长期做法：
– 把项目移到~/Documents（macOS/Linux）或%USERPROFILE%Documents（Windows）等本地可写路径
– WSL2 用户改用\wsl$distrohomeuserproject访问，避免/mnt/c/
– OneDrive 用户右键文件夹 → “始终在此设备上保留”，解除按需同步
真正容易被忽略的是：即使你修复了权限，只要路径仍在受控文件系统上，atomic_save: true 就可能持续静默失败——它不报错，也不写日志，只让保存变成“按了等于没按”。
