sublime text在wsl下保存失败主因是/mnt/c/路径与atomic_save冲突；应将项目移至wsl原生路径（如~/projects/），或关闭atomic_save、统一设utf-8编码，避免windows权限模型干扰。
Sublime Text保存失败，根本不是编辑器问题
Sublime Text 在 WSL 环境下无法保存文件，95% 以上的情况和 Sublime 本身无关——它只是被卡在了 Windows 和 Linux 权限模型的夹缝里。你点 Ctrl+S 没反应、控制台没报错、文件时间戳不动，大概率是写入路径落在 /mnt/c/ 这类挂载区，而 WSL 的 drvfs 挂载机制默认不支持原子重命名或权限透传。
为什么/mnt/c/路径下保存总静默失败
WSL 把 C:\ 映射为 /mnt/c/，但底层仍是 NTFS。Sublime 默认开启 atomic_save：先写 file.tmp，再 rename() 覆盖原文件。NTFS 不认 Linux 的 rename 语义，尤其当 OneDrive、Windows Defender 或资源管理器预览窗格锁住文件时，这步直接被拦截，且不抛异常。
-
atomic_save: true（默认）→ 在/mnt/c/下几乎必然静默失败 - 即使你手动
chmod 777目录，NTFS 实际不执行该操作，只做模拟映射 -
view.encoding()返回Western (Windows 1252)时，UTF-8 中文内容可能触发 Windows 层级写保护 - 终端执行
echo test > /mnt/c/path/file.txt若报 “Permission denied”，说明连系统级写入都不通，别调 Sublime 配置
真正有效的三步修复法
不重装、不 sudo、不改杀软，直击根因：
- 把项目挪到 WSL 原生路径（如
~/projects/），而不是/mnt/c/—— 这是最彻底的解法，ext4文件系统天然支持atomic_save和完整 POSIX 权限 - 若必须用
/mnt/c/，在 Sublime 的用户设置中强制关闭原子保存："atomic_save": false（仅调试用，断电时有丢数据风险） - 确认编码匹配：按
Ctrl+Shift+P→ 输入Set Encoding: UTF-8，避免 BOM 冲突引发 Windows 层拦截
别碰“以管理员身份运行”这个坑
右键 Sublime 快捷方式选“以管理员身份运行”，看似能绕过权限报错，实则让所有新建文件属主变成 root，后续 Git、npm、Python 脚本全会因 UID 不匹配报 EACCES。WSL 的权限一致性依赖 UID/GID 映射，不是靠提权硬怼。真要长期协作，该配 /etc/wsl.conf 里的 uid=1000 和 metadata，而不是每次开编辑器都提权。
