VSCode 搜索完全跳过只读文件，因其在扫描前通过系统 stat() 检查权限并直接跳过，search.exclude 等配置无效；必须修改系统级权限（如 Windows attrib -R、macOS xattr -d + chmod）才能使其参与搜索。
VSCode 无法限制搜索排除只读文件——它根本不会去“搜索”只读文件，更谈不上“排除”。只读文件在全局替换（Ctrl+Shift+H）和全局搜索（Ctrl+Shift+F）中都是静默跳过，不报错、不提示、不出现在结果里，你看到的“已替换 X 处”或“共找到 Y 处”完全不包含它们。
只读文件为什么搜不到？不是被排除，是压根没读
VSCode 在扫描文件前会调用操作系统 stat() 检查权限。一旦发现文件或其父目录标记为只读（Windows 的只读属性、macOS 的 com.apple.quarantine、Linux 的 chmod -w），就直接跳过整个路径，连内容都不读——这发生在 search.exclude 规则匹配之前。所以：
-
search.exclude和files.exclude对只读文件完全无效：它们只控制“该不该扫”，但只读文件连被扫的资格都没有 - 你在搜索面板右上角填的
Files to exclude也起不了作用：规则还没走到那一步，流程就终止了 - 没有配置项能绕过这个行为：VSCode 没有 “ignore readonly” 或 “force write” 开关，它严格遵循系统返回的权限状态
怎么确认某个文件是不是只读？
别猜，看实际状态：
- 已打开的文件：编辑器右下角显示 Read Only
- 未打开的文件：
ls -l path/to/file.ts（Linux/macOS/WSL）看权限位是否缺w；Windows 上右键 → 属性 → 查看“只读”复选框是否勾选 - 常见高危来源：
node_modules（npm install 后某些包带只读标志）、.d.ts（从 ZIP 解压）、OneDrive 同步卡住的文件、macOS 下下载的二进制或脚本（带quarantine属性）
唯一可行的操作：解除只读，别想绕过
想让某个只读文件参与搜索或替换，必须让它变成可写。不同系统操作不同，但核心就一条：改系统级权限，不是改 VSCode 设置。
- Windows：
attrib -R /S /D "path\to\folder"（递归清除只读属性），或右键 → 属性 → 取消“只读”→ 点“应用”时务必勾选“将更改应用于此文件夹、子文件夹和文件” - macOS：
xattr -d com.apple.quarantine <code>path/to/file.ts清除隔离属性，再chmod u+w <code>path/to/file.ts补写权限 - Linux/WSL：确保
ls -l输出中用户位含w（如-rw-r--r--），且父目录也有w权限（保存需重命名临时文件） - 千万别用管理员身份启动 VSCode 强行覆盖：可能破坏 Git 状态、触发签名验证失败、导致扩展崩溃
容易被忽略的关键点
很多人以为配好 search.exclude 就万事大吉，但只读文件的问题藏得更深：它不依赖任何 VSCode 配置，只依赖操作系统返回的 st_mode 标志。哪怕你把 search.exclude 清空、把 Files to exclude 输入框留空、甚至重载窗口，只要文件本身是只读的，它就永远不会出现在搜索预览或替换计数里——你永远不知道自己漏掉了什么，除非你主动检查权限。
