Sublime Text无内置只读开关，仅依赖系统级文件权限
想让Sublime Text文件变成只读，防止手滑改错？这事儿其实挺有意思的。Sublime Text本身并没有一个现成的“只读模式”开关。它完全依赖操作系统级的文件权限来判断文件是否可写。简单来说，你直接去改文件的系统属性，把它锁上，Sublime Text就会立刻“领会”意图，并拒绝任何保存操作。
核心逻辑就是：Sublime本身没有“只读模式”开关，它完全听操作系统的。文件被系统锁了，Sublime就会立刻拒绝保存。
Windows/macOS/Linux 怎么设系统级只读
这其实不是Sublime Text的功能，而是标准的文件系统行为——Sublime Text只是忠实地反映了操作系统内核返回的权限状态。方法如下：
- Windows系统：找到文件，右键点击选择“属性”，在弹出的窗口里勾选“只读”选项，然后点击“应用”。这里有个细节：记得点“全部应用”，否则可能只对当前文件生效，同目录下的其他文件权限没变。
- macOS系统：右键点击文件，选择“显示简介”，在信息窗口的最底部，找到并勾选“锁定”选项。
- Linux系统：在终端使用命令
chmod a-w filename。这里要特别注意，命令是a-w（给所有用户去掉写权限），而不是简单的chmod -w。少了那个a，可能只修改了当前用户的权限，其他用户仍然可以写入。
设置完成后，效果立竿见影。Sublime Text底部的状态栏会立刻显示 read only 的提示。这时候如果你尝试按 Ctrl+S 保存，会直接弹出一个错误窗口，提示：Unable to sa ve 。它甚至不会尝试去覆盖文件——因为操作系统内核根本就没有给它写入的权限入口。
为什么不能靠Sublime插件或设置实现只读
可能有人会想，既然软件本身没开关，那装个插件或者改改设置行不行？答案是：行不通。很多人尝试过禁用保存快捷键、隐藏保存菜单，甚至删掉保存命令，但这些方法都无效。原因很实在：
- Sublime Text的保存逻辑走的是标准的
fopen(..., "w")系统调用。一旦系统因为权限问题拒绝，它就报错，软件层面没有提供“拦截请求然后静默丢弃”这种中间钩子。 - 插件无法绕过操作系统内核的权限检查。即便有
on_pre_sa ve这类在写入前触发的事件，此时也已经无法阻止系统级的权限拒绝了。 - 所以说，真正的“只读编辑器”，其本质是“只读的文件系统”，而不是“在用户界面上假装只读的UI层”。
试图用插件来模拟只读状态，只会制造一种虚假的安全感。比如，用户可能复制粘贴了内容，误以为文件是受保护的，结果一按Ctrl+S，保存失败，反而可能造成内容丢失或混乱。
临时只读场景：用命令行打开更可靠
如果你经常需要临时预览一些配置文件或日志文件，又担心不小心误改，有没有更便捷的方法？使用命令行强制以只读方式打开，是一个更可靠的思路。
- 理论上，Windows、macOS和Linux都支持类似
subl --command "set_read_only"的命令。但这通常需要配合特定插件，而且稳定性并不理想。 - 更稳妥的做法是，先用系统命令设置好文件权限，再用Sublime Text打开。例如在Linux/macOS终端里：
chmod a-w config.json && subl config.json。 - 对于某些固定场景（比如在持续集成CI中查看生成的日志），可以写一个简单的shell脚本或批处理脚本进行封装：脚本自动给文件加锁 → 用Sublime打开文件 → 关闭编辑器后脚本再自动解锁文件。
需要特别注意的是，那个 set_read_only 命令并非Sublime Text的内置命令，需要用户自己手动注册命令类来实现，而且重启编辑器后可能就失效了。相比之下，直接操作文件权限的方案，要干净、彻底得多。
说到底，真正防止误改的关键，并不在Sublime Text的设置菜单里，而在你双击打开文件之前的那一步操作：确认文件的系统权限是否已经被锁定。所有试图在“软件应用层”实现只读的方案，都会在用户按下Ctrl+S的那一刻，暴露出它们的缺陷。
