“Permission denied”是macOS因无写权限拦截文件保存，非Sublime故障；安全做法是编辑后另存为用户目录再sudo cp，或用sudoedit调用终端编辑器，全程隔离权限。
Sublime 保存时提示 “Permission denied” 是什么信号
这不是 Sublime 坏了，而是 macOS 拦住了你——它检测到你正试图往自己没写权限的地方写文件，比如 /etc/hosts、/usr/local/bin 或 /Library/Preferences/ 下的配置。系统返回的是 EACCES 或 EPERM，Sublime 只是如实上报，不绕过、不妥协。
为什么 sudo /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl /etc/hosts 很危险
这条命令能让你点保存不报错，但代价远超收益：
- 整个 Sublime 进程（含所有插件、自动保存、GitGutter、Package Control 缓存）都以 root 身份运行，一不小心
Cmd+S就可能覆盖/etc/passwd或/var/db/.AppleSetupDone - macOS Catalina 及以后版本会直接拦截，报
LSOpenURLsWithRole() failed，窗口根本打不开 - 后续普通用户启动 Sublime 时，
Packages/User/目录若被 root 写入，Settings 就再也保存不了——你改 hosts 成功，却调不了字体大小 - 剪贴板失效、D-Bus 报错、拖放失灵等 GUI 异常是常态，不是偶发
真正安全的三步流程（推荐日常使用）
把“编辑”和“提权写入”彻底解耦，全程控制在你手里：
- 在 Sublime 中编辑完，按
Cmd+Shift+S→ 另存为~/Desktop/hosts.new（确保路径可写） - 终端执行：
sudo cp ~/Desktop/hosts.new /etc/hosts && sudo chmod 644 /etc/hosts - 验证：
sudo cat /etc/hosts确认内容已更新；再检查属主：ls -l /etc/hosts应显示root:wheel，权限为-rw-r--r--
这个流程里，Sublime 始终是普通用户进程，风险只发生在单次 cp 命令中，且你清楚知道写入了什么、写到了哪。
偶尔需要频繁改系统配置？用 sudoedit 更干净
它不启动 GUI 编辑器，而是调用你默认的终端编辑器（如 nano/vi），全程权限隔离，无缓存污染：
- 终端运行：
sudoedit /etc/nginx/nginx.conf - 保存退出后，文件属主和权限自动保持合规（
root:wheel+644） - 如果想用 Sublime 当默认编辑器，先设：
export EDITOR="/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl -w"，再运行sudoedit（-w参数让 Sublime 等待关闭才返回）
注意：sudoedit 的临时文件由系统管理，不会残留 root 权限的缓存或锁文件——这点比任何 sudo subl 都干净。
最易被忽略的点：Sublime 保存本质是「删旧文件 + 写新文件」，所以父目录必须有 w 和 x 权限。光给 /etc/hosts 加 u+w 不够，/etc/ 目录本身也得可写可进入。检查命令永远是 ls -ld /etc/，不是 ls -l /etc/hosts。
