vscode全局替换时只读文件会被静默跳过，不提示、不报错、不出现在搜索结果中；唯一解决方式是手动解除只读属性，无配置可绕过。
VSCode全局替换时只读文件会直接跳过，不是报错也不是灰掉
VSCode 的 Replace in Files 功能在执行批量替换时，对只读文件（右下角显示 Read Only）的处理方式是：静默跳过，不提示、不报错、也不出现在搜索结果列表中。你看到的“已替换 X 处”数字，只统计了成功写入的文件——那些被跳过的只读文件，连预览都不会给你看。
这意味着：你以为全项目都扫了一遍，其实 node_modules、dist、从 ZIP 解压出来的 .d.ts 文件、OneDrive 同步卡住的配置文件……只要系统标记为只读，VSCode 就自动绕开，连日志都不留一条。
- 检查只读状态最直接的方式：看编辑器右下角是否显示
Read Only；没打开的文件则完全不可见，无法预判 - 只读 ≠ 排除规则（
search.exclude）；即使你没配任何排除项，只读文件照样不参与搜索和替换 - Windows 上常见于下载/解压后未手动取消“只读”属性；macOS/Linux 则多因
com.apple.quarantine属性或挂载参数导致
如何让只读文件也参与全局替换？必须先解除只读，不能靠设置绕过
VSCode 没有“强制覆盖只读文件”的开关，也没有“忽略只读状态继续替换”的配置项。它严格遵循操作系统返回的权限状态。想让某个只读文件被替换，唯一可靠的做法是让它变成可写。
- Windows：右键文件 → “属性” → 取消勾选“只读”，点击“应用”时务必勾选“将更改应用于此文件夹、子文件夹和文件”
- 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 和 files.exclude 对只读文件无效？
这两个配置项只控制“可见性”和“可搜索性”，不干预文件系统权限。即使你在 search.exclude 里删掉了所有规则，VSCode 依然不会去读一个只读文件的内容；反过来，就算你把它显式加进 files to include，只要它是只读的，就不会出现在替换预览里。
-
search.exclude是告诉 VSCode “别去这些路径下扫描”，但扫描前就发现文件只读 → 直接跳过，根本不到扫描那步 -
files.exclude只影响左侧资源管理器显示，跟搜索逻辑完全无关 - 真正起作用的是操作系统级的
stat()系统调用返回的st_mode标志位，VSCode 只是忠实反映
替换前快速识别潜在只读文件的实操技巧
大型项目里，你很难逐个点开每个匹配文件看右下角。更现实的做法是提前筛出高风险路径，集中处理。
- 在终端执行：
find . -name "*.ts" -perm -u=r -not -perm -u=w | head -20（Linux/macOS/WSL），列出前 20 个用户可读但不可写的 TS 文件 - Windows PowerShell：
Get-ChildItem -Recurse -Include "*.ts" | Where-Object { !$_.IsReadOnly }反向查非只读文件，对比总数能估出只读比例 - 重点关注：
node_modules/**/*（npm 包自带只读标志）、src/generated/（代码生成器输出）、**/*.d.ts（声明文件常被设为只读） - Git 仓库里已提交的文件一般可写；但刚克隆完的 repo 若用 OneDrive 同步，首次打开时常批量带 quarantine 属性
