files.readonlyinclude是vs code 1.80+唯一有效的只读配置项，支持glob匹配路径并强制只读ui行为；需配合系统级只读权限（如windows属性勾选或chmod 444）才能真正防止误改。
files.readonlyInclude 是唯一真正起效的配置项
VSCode 1.80+ 版本已弃用 files.readonly，官方只保留 files.readonlyInclude 这个对象型配置，它支持 glob 模式匹配路径，并在文件打开时强制触发只读 UI 行为（禁用编辑区输入、灰掉保存按钮、显示 “Read-only” 水印）。它不改系统权限，但能拦截绝大多数误操作。
常见错误现象：加了 "files.readonly": ["**/core/*.ts"] 却完全没反应——因为该字段早已被移除，VSCode 忽略它且不报错。
- 路径必须基于工作区根目录，比如项目根下有
src/lib/core/utils.ts，则写"**/core/**/*.ts"才能匹配 - 单星号
*只匹配当前层级，**才递归；漏掉一个星号就失效 - 修改后必须关闭所有已打开的匹配文件，再重新打开才生效（不会热更新）
- 不支持正则，只认 minimatch 语法；
**/core/**/*.{ts,js}是合法写法
系统级只读才是防绕过的最终防线
仅靠 files.readonlyInclude 不够。用户仍可通过 File → Save As 另存为、或粘贴覆盖内容后点保存（此时会弹 Unable to write file 'xxx' (NoPermissions)），但前提是文件本身没设系统只读。真要“手滑也改不了”，必须叠加操作系统权限。
- Windows：右键文件 → 属性 → 勾选“只读” → 点“应用” → 勾选“将更改应用于此文件夹、子文件夹和文件”
- macOS/Linux：终端执行
chmod 444 src/lib/core/utils.ts（注意不是 644，444 才是只读） - Git 仓库中文件可能被
git checkout重置权限，需同步执行git config core.filemode false - 别对整个
node_modules目录设 444——chmod 对目录无效，且会破坏 npm/yarn 安装逻辑
为什么改完设置还能 Ctrl+S 成功？三个高频原因
看到“Read-only”提示却仍能保存成功，不是 VSCode 失效，而是某一层权限链松动了：
- 文件已在编辑器中打开，改了
settings.json后没关标签页 → VSCode 不动态重载只读状态 - 用了 Remote - SSH 或 Dev Containers → 权限判断发生在远程机器上，本地
readonlyInclude不生效 - 启用了
files.saveWithoutWatching（默认为true）→ 它会跳过只读检查直接调用 fs.write，必须手动设为false
验证是否真生效：关闭所有相关文件 → 重新打开 → 按 Ctrl+S，确认弹出 Cannot save... File is read-only 而非静默成功。
团队协作时最常被忽略的落地细节
把 .env 或 config.production.json 加进 readonlyInclude 很容易，但别人 clone 仓库后根本不会自动继承这个设置——它只存在于你本地的 .vscode/settings.json，而该文件通常被 .gitignore 排除。
- 若需统一策略，应把配置放进
.vscode/settings.json并提交到仓库（前提是团队接受共享编辑器设置） - 更稳妥的做法：用 pre-commit hook +
git diff --cached检查敏感文件是否被修改，拦截提交 -
readonlyInclude对符号链接（symlink）无效；如果核心代码通过 ln -s 引入，得给源文件设权限，而非链接本身 - VSCode 不识别 Git 的 index-only 只读状态（如刚
git checkout后），它只看fs.accessSync(path, fs.constants.W_OK)返回值
