VSCode 本身不提供“全局只读开关”，需通过 files.readonlyInclude 配置 + 文件系统权限双管齐下防误改：前者匹配路径禁保存并报错，后者（如 chmod 444 或 Windows 属性设只读）从系统层锁死写入，缺一不可。
VSCode 本身不提供“全局只读开关”，但能通过 files.readonlyInclude 配置 + 文件系统权限双管齐下，真正拦住对 node_modules 等核心库源码的误保存。
为什么直接改 node_modules 里的文件很危险
你打开 lodash/index.js 看实现，顺手删了一行、按了 Ctrl+S——VSCode 就真把它写回磁盘了。这不是“没提示”，是根本没设防。npm install 重装后这些改动会消失，但若你忘了还原、又提交了修改，CI 构建可能突然失败；更糟的是，某些本地 patch 被当成真实行为依赖，上线后直接报错。
- VSCode 不会自动识别
node_modules是第三方代码，它只认路径和权限 - Git 默认不跟踪
node_modules，所以这类误改不会进 commit，但会污染本地运行时环境 - 编辑器里显示“Read-only”水印 ≠ 禁止编辑，只是 UI 提示；真正拦截保存动作的，是操作系统返回的写权限检查
files.readonlyInclude 是唯一靠谱的路径级只读配置
这是 VSCode 1.80+ 唯一支持的、按 glob 模式匹配路径并强制只读的设置。它不改文件权限，但会让编辑器在打开匹配文件时禁用 Ctrl+S、显示 ? Read-only 标签，并在点击保存按钮时明确报错 Unable to write file 'xxx' (NoPermissions)。
- 必须写在工作区根目录的
.vscode/settings.json中才最稳妥（避免影响其他项目） - 匹配基于工作区根目录，不是绝对路径，例如：
"**/node_modules/**/*.js"会匹配所有 JS 文件，"**/node_modules/**/*"更彻底 - 别用
files.readonly（已废弃）或workbench.editor.readonly（根本不存在） - 改完需重启 VSCode 或关闭再重新打开该文件，设置才会生效
示例配置：
{
"files.readonlyInclude": {
"**/node_modules/**/*": true,
"**/yarn.lock": true,
"**/pnpm-lock.yaml": true
}
}
必须配合文件系统权限才真正防得住
files.readonlyInclude 只控制编辑器行为，不能阻止命令行或外部工具写入。如果某天你执行了 echo "bad code" > node_modules/lodash/index.js，VSCode 的配置完全无效。所以关键一步：让系统层面也不允许写。
- macOS/Linux：终端执行
chmod -R 444 node_modules/（注意：444 是只读，644 仍可写） - Windows：右键
node_modules文件夹 → 属性 → 勾选“只读” → 应用于所有子对象 - Git 用户注意：
git checkout或git pull可能重置文件权限，建议加git config core.filemode false关闭 Git 对文件模式的追踪 - 不要对整个
node_modules目录设chmod 444后还运行npm install——它会失败。只读权限应在开发阅读阶段启用，安装依赖前手动恢复（chmod -R 755 node_modules）
容易被忽略的边界情况
你以为设了 files.readonlyInclude 就万事大吉？这几个点实际踩过坑的人才知道：
-
Save As（另存为）始终可用，哪怕文件是只读的——VSCode 不拦截这个操作，用户可能无意中把改过的index.js另存为新文件，回头又 import 错路径 - 插件如 Prettier、ESLint Fix on Save 仍可能尝试格式化只读文件，触发权限错误弹窗，打断流程
-
search.exclude和files.exclude只隐藏文件，不影响可编辑性，别指望它们防误改 - Live Share 会话中，访客默认是只读，但主机若授予 Edit 权限，对方仍可修改——此时只读配置只在主机端生效，访客端不继承
真正可靠的防线永远在两层：系统权限锁死写入能力，VSCode 配置补上编辑器层的明确反馈。少一层，就多一分误操作风险。
