vscode中真正起效的只读配置只有files.readonlyinclude（1.80+版本）或系统权限修改；旧版不支持、配置层级被覆盖、未重启窗口、glob路径错误均会导致设置失效。
VSCode 没有“设为只读”的一键开关，真正起效的只有两种路径：改文件系统权限（彻底锁死），或配 files.readonlyInclude（编辑器层拦截保存）。其他所谓“只读模式”设置，基本是过时、无效或误导的。
为什么改了 settings.json 还能保存成功？
常见原因不是配置写错了，而是 VSCode 没触发只读逻辑：
-
files.readonlyInclude是 1.80+ 版本才正式支持的配置项，旧版 VSCode（如 1.79 及更早）不识别它；网上很多教程混用了已弃用的files.readonly，加了也白加 - 配置写在用户级
settings.json里，但项目工作区（.vscode/settings.json）里有同名项，会被覆盖 - 文件已在编辑器中打开，改完配置后没关闭重开 —— VSCode 不会动态重载只读状态，必须重启窗口或重新打开该文件
- 路径 glob 写错，比如想匹配
node_modules却写了"node_modules/**"（缺开头**/），导致不生效
files.readonlyInclude 怎么配才真正拦截保存？
这是目前最实用、跨平台、不破坏命令行工具的方案，专用于防止误存（不是防编辑）：
- 必须写进项目根目录下的
.vscode/settings.json，例如："files.readonlyInclude": { "**/package-lock.json": true, "**/yarn.lock": true, "**/node_modules/**": true, "**/.env*": true } - 双星号
**表示递归匹配，单星号*只匹配当前层级，漏掉子目录就失效 - 匹配的是相对于工作区根目录的路径，不是绝对路径，也不是相对于用户主目录
- 配置生效后，Ctrl+S 会弹出
Cannot save... File is read-only，但你仍可输入、删改、复制 —— 它只拦保存，不拦编辑
怎么让文件“真的不能改”？靠操作系统权限
编辑器层防护可以绕过（比如另存为、外部命令写入），真要锁死，必须走系统层：
- Windows：右键文件 → “属性” → 勾选“只读” → 点确定；注意：对文件夹勾选只读仅影响新建文件，不影响已有子文件
- macOS/Linux：终端执行
chmod 444 文件名（不是644，后者仍可写）；chmod -R 444 node_modules会破坏 npm/yarn/pnpm 正常运行，切勿对整个node_modules目录递归设只读 - Git 仓库里的文件默认是只读的，但 VSCode 不看 Git 状态，只认
fs.access()返回的权限，所以git pull后仍需手动设权限或依赖files.readonlyInclude - VSCode 检测到只读权限后，右下角显示
Read-only，禁用 Ctrl+S，但File → Save As仍可用 —— 因为那是另存为新文件，不违反原文件权限
哪些操作会绕过只读防护？
别高估任何只读设置的强度，这些行为都能跳过：
- 用命令行直接覆盖：比如
echo "xxx" > config.json，VSCode 完全不知情 - 插件自动保存：某些 Auto Save 类插件会忽略编辑器只读状态，强行写入
- Remote - SSH 场景：只读判断发生在远程服务器端，本地
files.readonlyInclude配置无效 - 通过
File → Save As另存为同名文件（在 Windows 上可能触发系统覆盖确认，但 macOS/Linux 默认静默覆盖）
最稳的组合是：files.readonlyInclude + 系统只读属性（针对极少数关键文件），再配合 .gitignore 和提交前检查，才能覆盖多数误改场景。记住：VSCode 的只读永远是“提示+拦截”，不是“锁死”。
