Sublime Text 的只读状态完全依赖文件系统权限，而非编辑器配置；Windows 通过属性勾选“只读”，macOS 用“锁定”，Linux 执行 chmod a-w；插件实现的仅是软只读，无法替代系统级防护。
Sublime Text 本身没有“只读模式开关”，它只响应文件系统是否允许写入——也就是说，只读不是编辑器功能，而是操作系统权限状态。你设了 is_read_only: true 这类配置项，Sublime 不会理；但只要文件被系统标记为不可写，它立刻在底部显示 read only，且按 Ctrl+S 时直接报错：
Unable to save <filename>: Permission denied</filename></p> <H3>怎么让 Sublime 真正识别只读状态</H3> <p>必须从文件系统层面设置权限，Sublime 才会检测并生效：</p> <ul> <li>Windows：右键文件 → 属性 → 勾选“只读” → 点“应用”，再点“全部应用”（否则同目录下其他文件可能没生效）</li> <li>macOS：右键 → “显示简介” → 拉到底部勾选“锁定”</li> <li>Linux：<code>chmod a-w filename（注意是
a-w，不是 -w；少个 a 只改当前用户权限，别人仍可写）
设置后，Sublime 底部状态栏立刻变灰显示 read only，且编辑后无法保存——不是弹窗提醒，而是内核直接拒绝写入，连临时缓存都不生成。
为什么插件的 Toggle Read-Only 不等于系统只读
像 Read Only Mode 或 FileReadOnly 这类插件，只是在 Sublime 内部拦截编辑和保存动作，并不修改文件权限：
- 它们靠监听
on_modified和重写save命令实现“软只读” - 关闭插件或重启 Sublime 后，只读状态即失效
- 文件仍可被其他程序（如 VS Code、记事本）正常修改并保存
- 对大文件查看场景有用，但不能替代系统级防护
这类插件适合临时查看配置、日志，但别指望它保护生产环境的 nginx.conf 或 hosts 文件。
项目级只读：用 is_read_only 配置没用，但可以绕过
Sublime 的项目设置（Project → Edit Project）里写 "is_read_only": true 是无效的——官方文档没这个字段，也不被解析。但你可以结合插件做条件触发：
- 安装
Read Only Mode后，在项目设置中加自定义字段，如"project_readonly": true - 再写个简单插件监听
on_load事件，检查该字段并自动执行view.set_read_only(True) - 这样打开整个
src/目录下的文件就默认锁住，但需手动维护逻辑
纯配置方案走不通，硬要项目级控制，就得写几行 Python 插件代码，而不是堆 JSON。
大文件只读 + 性能优化必须一起做
只设只读还不够。打开几百 MB 的日志时，即使不编辑，语法高亮、行号、minimap 也会卡死界面。必须同步关掉这些渲染项：
- 在用户设置中加：
"large_file_size_limit": 100（单位 MB，超限后自动降级为只读+无高亮） - 手动关闭：
"word_wrap": false、"draw_white_space": "none"、"highlight_line": false - 打开文件后，点击底部语言名 → 选
Plain Text，彻底禁用语法分析
只读防止误改，关渲染防止卡顿——两者缺一不可。很多人只做一半，结果还是等三分钟才能滚动。
真正可靠的只读，永远落在文件系统上。编辑器只是镜子，照出权限状态而已。别在配置里找开关，去改 chmod 或右键属性才是正解。
