sublime text 的只读依赖操作系统权限，非软件设置；系统级锁定后状态栏显示“read only”且保存报错，插件仅ui遮挡、不改权限；大文件需结合chmod与降级配置防卡顿。
只读靠系统权限，不是Sublime设置
Sublime Text 没有“软件层只读开关”，is_read_only 这类配置项不是原生支持的设置项，强行写进用户或项目配置里不会生效。它只响应操作系统返回的文件可写状态——fopen(, "w") 系统调用失败，就直接报 Permission denied，不给你任何“拦截后静默丢弃”的机会。
常见错误现象：你改了用户设置加了 "is_read_only": true，重启后没反应；或者装了插件点“Toggle Read Only”，Ctrl+S 仍能保存成功——说明文件本身在系统层面仍是可写的，插件只是 UI 层遮挡，一绕就破。
- Windows：右键文件 → “属性” → 勾选“只读” → 点“应用”，再点“全部应用”（否则同目录其他文件可能漏设）
- macOS：右键 → “显示简介” → 底部勾选“锁定”
- Linux：
chmod a-w filename（注意是a-w，不是-w；少个a只改当前用户，别人仍可写）
设完立刻生效：Sublime 底部状态栏会显示 read only，Ctrl+S 弹窗报错，且不会尝试覆盖——内核根本没给写入口。
Read Only Mode 插件适合临时查看，但别信它防误改
插件如 Read Only Mode 能在右键菜单或命令面板（Ctrl+Shift+P → Read Only: Toggle）里切换状态，状态栏也显示只读，但它不改文件权限，仅禁用 Sublime 内部编辑事件（如按键输入、粘贴），on_pre_save 事件甚至都收不到——因为保存流程在插件介入前就被系统拒绝了。
使用场景有限：
- 快速预览自己刚写的配置，怕手滑保存 → 插件够用
- 团队共享只读模板文件，但文件本身未锁 → 插件提供一层心理提示
- 配合项目设置做条件判断（比如检测到某路径就自动启用插件只读）→ 需额外写命令类，稳定性差
性能/兼容性影响：插件本身轻量，但若和 Vintage、SideBarEnhancements 等插件冲突，可能触发 KeyError 或状态栏不更新；2026 年最新版 Sublime 中，部分插件未适配 API v4，启用后右键菜单消失是已知问题。
大文件只读 + 降级模式才是真防卡+防误改
打开 GB 级日志或导出数据时，“防止修改”和“不卡死”得一起解决。单设系统只读还不够，得让 Sublime 主动放弃编辑逻辑：
- 先用系统命令锁文件：
chmod a-w app.log && subl app.log - 在用户设置（
Preferences → Settings右侧）加关键项：{ "large_file_size_limit": 100, "index_files": false, "detect_indentation": false, "word_wrap": false, "syntax": "Packages/Text/Plain text.tmLanguage" } -
large_file_size_limit单位是 MB，设为100后，超 100MB 的文件跳过语法分析；index_files: false是关键，否则后台默默建索引，CPU 拉满
别依赖 subl --command "set_read_only"：这不是内置命令，需手动注册，重启即失效；不如一行 chmod 加 subl 干净可靠。
项目级只读只能靠外部脚本兜底
想让整个 config/ 目录下所有文件默认只读？Sublime 不支持目录级权限设置，"settings": {"is_read_only": true} 在项目配置中纯属无效字段。唯一靠谱做法是用 shell/bat 封装工作流：
- 查看前自动加锁：
find config/ -type f -exec chmod a-w {} \; - 打开后自动解锁（关闭 Sublime 后）：
find config/ -type f -exec chmod u+w {} \; - CI 日志查看等一次性场景，这种“开锁→编辑器→关锁”链路比任何插件都稳
真正容易被忽略的点：很多人以为“点了插件只读按钮”就安全了，结果复制一段内容粘贴进已锁文件，再 Ctrl+S——弹窗报错，但此时剪贴板内容已覆盖原缓冲区，下次打开若忘了重载，看到的就是错乱内容。防误改的关键永远在双击打开前那一步：确认文件是否已被系统锁定。
