根本原因是windows文件系统层对wsl2挂载路径的双重限制：路径转义后长度翻倍突破260字符，且movefileex对重命名路径容忍度低于createfilew，导致atomic_save的rename环节被静默拦截；验证用test-path与echo测试，绕过方式优先选用wsl2原生路径、网络驱动器映射或临时禁用atomic_save。
为什么Sublime Text打开/mnt/c/路径会静默保存失败
根本原因不是Sublime本身，而是Windows文件系统层对WSL2挂载路径的双重限制：一方面路径经/mnt/c/Users/name/project转义后实际长度翻倍（比如/mnt/c → wsl$Ubuntuhomeuser），轻易突破260字符；另一方面，Windows对MoveFileEx（用于atomic_save重命名）的路径容忍度比CreateFileW更低，导致rename环节直接被拦截，且不报错。
验证是否为WSL2路径导致的问题
在Sublime控制台（Ctrl+`）中执行：view.file_name()，复制输出路径，然后在PowerShell中运行：Test-Path "你的完整路径"。若返回False，再用echo test > "你的完整路径"测试写权限——如果也失败，基本锁定是WSL2路径翻译+系统级写入拦截组合问题。
绕过/mnt/c/路径的三种实操方式
优先级从高到低：
- 把项目移到WSL2原生文件系统下（如
~/code/project），用Sublime通过\wsl$Ubuntuhomeusercodeproject访问——此路径不受MAX_PATH限制，且避免/mnt/c/的符号链接陷阱 - 映射网络驱动器：在CMD中执行
net use X: "\wsl$Ubuntuhomeusercode"，再用Sublime打开X:project ile.py——注意不能手动拼?X:...，必须由net use生成 - 禁用atomic_save仅限调试：在Project Settings里加
"atomic_save": false，让Sublime直接覆盖而非rename；但长期关闭会失去断电保护，不建议全局设置
别忽略OneDrive和“按需同步”的干扰
即使路径合法，若项目目录启用了OneDrive“文件按需同步”，或位于NAS、加密卷等非本地NTFS分区，rename操作仍会被拦截——这是Windows受控文件夹访问（CFW）机制主动阻断，与Sublime无关。临时方案是右键OneDrive托盘图标 → “暂停同步”，或把项目移出同步目录。真正稳定的路径只有两类：本地NTFS下的短路径（如C:p），或WSL2原生~目录下的路径。
