files.readonlyInclude是VS Code 1.80+唯一有效的只读配置项，需以glob路径为key、true为value的对象格式配置，匹配文件须关闭后重新打开才生效，且必须叠加系统级只读权限（如chmod 444或Windows属性勾选）才能真正防误改。
files.readonlyInclude 是唯一有效的配置项
VS Code 1.80+ 版本已彻底移除 files.readonly，改用 files.readonlyInclude 这个对象型配置。它不接受数组，只接受键值对：路径 glob 为 key，true 为 value。写错字段名或类型（比如仍用数组），VS Code 会静默忽略，毫无提示。
常见错误现象："files.readonly": ["**/.env"] 看似合理，但完全无效；右下角不显示 Read-only，Ctrl+S 仍能成功保存。
- 路径必须基于工作区根目录，例如项目根下有
src/config/env.prod.json，则匹配写法是"**/config/env.prod.json"或更泛的"**/config/**.json" -
**表示递归任意层级，*只匹配单层目录或文件名；漏掉一个星号就失效 - 不支持正则，只认
minimatch语法，"**/*.lock"合法，"**/package-lock\.json"中的反斜杠会被当字面量处理，反而失配
为什么改了配置却没反应？
VS Code 不会对已打开的文件动态应用 files.readonlyInclude。修改配置后，必须关闭所有匹配路径的文件标签页，再重新打开——不是重载窗口（Developer: Reload Window），而是真正关闭再打开。
常见错误现象：配置写对了，也点了重载窗口，但文件还能编辑、Ctrl+S 也不报错——因为文件标签页一直开着，VS Code 没重新走只读判定逻辑。
- 确认你改的是工作区设置（
.vscode/settings.json），不是用户设置；用户级配置会被工作区覆盖 - 检查文件是否通过拖拽进已有窗口打开；推荐用
File → Open File…或命令行code /path/to/file单独启动，确保走完整加载流程 - 某些插件（如 Prettier、ESLint Auto Fix）可能在保存前自动格式化并触发写入，临时禁用它们再测试
仅靠配置无法真正阻止修改
files.readonlyInclude 只控制编辑器行为：灰掉输入框、禁用 Ctrl+S、加水印。但它不阻止你粘贴内容、全选删除、甚至用鼠标拖动光标——只是保存时才拦截。用户仍可复制全部内容 → 新建文件 → 粘贴 → 保存为同名文件，绕过限制。
真要“手滑也改不了”，必须叠加系统级只读权限：
- Windows：右键文件 → 属性 → 勾选“只读” → 点“应用”，并勾选“将更改应用于此文件夹、子文件夹和文件”
- macOS/Linux：终端执行
chmod 444 path/to/file（注意不是644，444才是只读） - Git 仓库中，
git checkout可能重置权限，需同步执行git config core.filemode false
此时 VS Code 会进入强只读状态：光标不可定位、Del 键无效、右下角锁图标变实心，这才是物理级防护。
node_modules 和 lock 文件怎么安全设只读
对 node_modules 目录不能直接 chmod -R 444，否则 npm install、yarn build 等命令会失败。正确做法是纯编辑器层防护：
- 在项目
.vscode/settings.json中写："files.readonlyInclude": { "**/node_modules/**": true, "**/package-lock.json": true, "**/yarn.lock": true } - pnpm 用户额外加：
"**/.pnpm/**": true；Yarn 2+/3+ 用户加："**/.yarn/cache/**": true - 别用
"**/node_modules/*"—— 它匹配不到node_modules/lodash/es/index.js这类深层路径 - 该设置不影响
npm、webpack等 CLI 工具，只约束 VS Code 编辑行为
真正麻烦的是那些被开发者手动打开、又顺手保存的 node_modules 源码文件。一旦保存，就污染了依赖包——这种误操作只能靠 files.readonlyInclude + 团队规范双重卡住。
