sublime text 保存失败的根本原因是路径权限不足，需同时满足文件属主为当前用户且父目录具备可写可执行权限；atomic_save和encoding配置不当也会导致静默失败。
Sublime Text 能否正常保存文件，不取决于它装没装好，而取决于你当前操作的路径是否允许你“删旧 + 写新”——这是所有保存失败的底层逻辑。直接改权限，比重装、换源、禁插件快得多。
检查文件和父目录的写权限是否都满足
Sublime Text 保存不是覆盖写，而是先 unlink() 旧文件再 write() 新文件。所以仅给文件加 w 权限完全无效，必须同时满足：
- 文件属主是你自己，且权限含
-rw-（Linux/macOS 用ls -l /path/to/file查） - 父目录权限含
drwx且第三段有w（ls -ld /path/to/parent查），x位也必须存在，否则无法进入目录执行删除 - Windows 上右键 → “属性” → 确认“只读”未勾选；macOS 上右键 → “显示简介” → 底部“锁定”已关闭
atomic_save 和 encoding 配置会静默导致保存失败
这两个设置不报错，但会让你反复按 Ctrl+S 却毫无反应：时间戳不变、内容没更新、控制台也无输出。
-
atomic_save默认为true：Sublime 先写xxx.tmp，再rename()替换原文件；若父目录不可写，tmp创建失败，整个保存就静默终止 -
encoding不匹配（比如文件是UTF-8 with BOM，但 Sublime 以Western (Windows 1252)打开并保存），部分 Windows 系统会拦截写入，返回EACCES - 临时验证：
view.encoding()若返回Western (Windows 1252)或undefined，立刻菜单 →File → Save with Encoding → UTF-8 - 调试时可在
Preferences → Settings中设"atomic_save": false，但长期关闭有数据丢失风险
别用 sudo subl 或“以管理员身份运行”长期编辑
这看似能绕过报错，实则埋下严重隐患：
- Package Control 缓存（如
~/.config/sublime-text-4/Cache/或~/Library/Application Support/Sublime Text/Packages/User/）被root写入，下次普通用户启动直接失效 - 保存的
/etc/nginx/nginx.conf属主变成root，后续nginx -t或git commit因权限不一致而失败 - macOS Catalina+ 会直接拦截，报
LSOpenURLsWithRole() failed；Linux 下还常引发 D-Bus 报错、剪贴板失效 - 真正安全的操作是分离「编辑」和「写入」：在 Sublime 中按
Cmd+Shift+S（macOS）或Ctrl+Shift+S（Win/Linux）另存到~/Desktop/，再用终端提权写入，例如：sudo cp ~/Desktop/nginx.conf /etc/nginx/nginx.conf
Settings 文件无法保存的特殊处理
Preferences.sublime-settings 保存失败，通常不是权限不够，而是 Sublime 把用户设置路径指向了错误位置，或者 Packages/User 文件夹本身被锁住了。
- 打开
Preferences → Browse Packages…，确认跳转的是你自己的用户目录（如~/Library/Application Support/Sublime Text/Packages/User/），而不是系统级路径 - 终端执行
ls -ld ~/Library/Application\ Support/Sublime\ Text/Packages/User/，确保属主是你自己，且权限含drwx - 如果该目录属主是
root，运行sudo chown -R $USER:staff ~/Library/Application\ Support/Sublime\ Text/Packages/User/修复 - Windows 用户注意：
Packages/User若在 OneDrive 同步中，可能被后台进程占用，导致保存失败
最易被忽略的一点：保存失败时右下角状态栏显示的路径，往往就是问题根源——/usr/local/bin、/etc/、C:\Program Files\ 这些路径默认就不给你写权限。别跟系统较劲，换路径、改权限、分步写入，三者选一，事情就结束了。
