系统级只读是唯一真正生效的防护手段，Sublime Text无内置只读模式；必须在打开文件前通过Windows勾选“只读”、macOS勾选“锁定”、Linux执行chmod a-w设置文件权限，设后状态栏显示“read only”，Ctrl+S直接报“Permission denied”，不缓存、不提示放弃修改。
系统级只读才是唯一生效的防护手段
Sublime Text 没有“开启只读模式”这回事，所有编辑器内设置（比如 set_read_only、插件、用户配置项）都只是软标记，不改文件权限位，Ctrl+S 时照样被操作系统拒绝——而且是当场报错，不缓存、不提示放弃修改。
真正起作用的，只有你在打开文件前，就用操作系统命令锁死写权限：
- Windows：右键文件 → “属性” → 勾选“只读” → 点“应用”，再勾选“将更改应用于此文件夹、子文件夹和文件”（否则同目录下其他文件漏锁）
- macOS：右键 → “显示简介” → 滚动到底部 → 勾选“锁定”（不是“共享与权限”里的读写设置）
- Linux/macOS：终端执行
chmod a-w /path/to/file（注意是a-w，不是-w；少个a只改当前用户，组或其他人仍可写）
设完立刻生效：Sublime 底部状态栏显示 read only，按 Ctrl+S 弹窗报错 Unable to save <filename>: Permission denied。
为什么 view.set_read_only(True) 不可靠
在控制台执行 view.set_read_only(True) 或装 Read Only Mode 插件，只能让标题栏显示 [readonly]、粘贴删除时弹确认框，但这些全是视图层标记，不碰文件系统权限。
一旦你手动调用 view.set_read_only(False)，或通过 Python 控制台、其他插件绕过 UI 层，保护就失效。更关键的是：save_on_focus_lost 和原生保存流程完全不检查这个标记，它们直接走 fopen(filename, "w")，系统拒了才报错。
所谓“软只读”，本质是信任用户不手贱——但防误操作，恰恰不能靠信任。
临时查看日志/配置时怎么安全打开又自动解锁
别信 subl --command "set_read_only" 这类命令——它不是内置命令，需手动注册、重启即失效、稳定性差。真正可靠的做法是用 shell/bat 封装系统命令：
- Linux/macOS：
chmod a-w config.yaml && subl config.yaml && chmod u+w config.yaml - Windows（PowerShell）：
attrib +R config.yaml; subl config.yaml; attrib -R config.yaml
重点在于：只读保护是否生效，只取决于你双击打开 Sublime 前那一步——文件是否已被系统锁定。任何“先打开再设只读”的操作，都在保存那一刻暴露缺陷。
固定标签页 ≠ 锁定内容，二者必须叠加使用
TabsExtra 插件能让你右键标签页选择 Sticky Tab，防止被 Ctrl+W 或 Close All Tabs 关掉，但它不阻止编辑、不防保存覆盖，只是“关不掉”。
真正需要保护的文件（如 /etc/hosts、部署模板），得双重锁定：
- 先用系统命令设只读（
chmod 444或 Windows 属性勾选“只读”） - 再在
Sublime中打开，控制台输入view.set_read_only(True)
此时文件不可编辑、不可保存（Ctrl+S 会弹确认框）、标题栏显示 [readonly]，且标签页还能固定住——系统只读是硬限制，view.set_read_only(True) 是软提示，缺一不可。
