因为sublime保存是“删旧建新”而非覆盖写入，仅chmod u+w文件无效，必须确保父目录有w+x权限、关闭系统级锁定/只读属性，并检查atomic_save和encoding设置。
为什么 chmod u+w 文件本身没用
Sublime Text 保存不是“覆盖写入”，而是先 unlink() 删除原文件，再 open(O_CREAT|O_WRONLY) 创建新文件。所以仅给文件加写权限（chmod u+w /etc/hosts）完全无效——父目录必须允许你创建和删除文件。
- Linux/macOS：运行
ls -ld /etc/，若输出以dr-xr-xr-x开头（第三段无w），说明目录不可写；修复命令是sudo chmod u+w /etc/ - Windows：右键目标文件夹 → “属性” → “安全” → 编辑 → 找到你的用户名 → 勾选“修改” → 点“应用” → 勾选“将更改应用于此文件夹、子文件夹和文件”
- macOS 还要关掉右键 → “显示简介” → 底部“锁定”开关；Windows 文件属性里“只读”勾选必须取消
atomic_save 和 encoding 是静默失败的元凶
这两个设置不报错，但会让你反复按 Ctrl+S 却毫无反应，控制台也无日志：
-
atomic_save默认为true：Sublime 先写xxx.tmp，再rename()替换原文件；OneDrive、NAS、WSL2 的/mnt/c/路径常拦截rename，导致静默失败 -
encoding不匹配：比如文件实际是 UTF-8 with BOM，但 Sublime 以 Western (Windows 1252) 打开并保存，部分 Windows 系统会触发写保护 - 快速验证：按
Ctrl+`打开控制台，输入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（Windows/Linux）另存到桌面，再用sudo cp ~/Desktop/nginx.conf /etc/nginx/nginx.conf
对 /etc/ 等系统路径，优先用 sudoedit 或 tee
这类路径本就不该由 GUI 编辑器直接写入，更稳妥的方式是让权限隔离干净：
-
sudoedit /etc/hosts：自动调用默认编辑器（可设为subl -w），保存后sudoedit自动用 root 权限写回，Sublime 进程全程以普通用户运行 -
echo '127.0.0.1 example.com' | sudo tee -a /etc/hosts：适合单行追加；多行内容可用printf '%s\n' 'line1' 'line2' | sudo tee /etc/hosts > /dev/null - 如果非要 Sublime 编辑，先
sudo chmod u+w /etc/hosts，改完立刻sudo chmod u-w /etc/hosts，避免遗留风险
最易被忽略的点：父目录的 x（执行）权限。没有它，你就进不去目录，更别说删文件或建 tmp；而 macOS 的“锁定”和 Windows 的“只读”属性，根本不在 chmod 或 icacls 控制范围内，必须单独关掉。
