files.exclude 未生效主因是配置位置错误或语法不合规，它仅影响资源管理器显示和项目搜索，不控制文件监视和语言服务索引；需写在工作区 .vscode/settings.json 中，且 glob 规则须准确（如用 "node_modules/" 而非 "/node_modules/**"）。
files.exclude 为什么没生效？检查作用域和语法格式
VSCode 的 files.exclude 只影响资源管理器显示和项目搜索（Ctrl+Shift+F），**不控制文件监视或语言服务索引**——这是很多人误以为“排除后搜索变快”的根本原因。它真正起效的前提是：配置写在工作区根目录的 .vscode/settings.json 中，且语法必须严格符合 glob 规则。
- 错误写法：
"**/node_modules/**"（多出开头的**/，VSCode 会忽略整条规则） - 正确写法：
"node_modules/**"或"**/node_modules" - 路径区分大小写：Windows 上
"build/**"不会匹配BUILD/，需显式加"BUILD/**" - 排除单个文件要带扩展名：
"package-lock.json"，不能只写"package-lock"
搜索仍慢？你可能漏掉了 search.exclude
files.exclude 管显示，search.exclude 才真正跳过搜索扫描。两者常被混用，但效果完全不同。如果项目里有大量日志、构建产物或临时文件夹，仅靠 files.exclude 无法提速全局搜索。
-
search.exclude默认继承files.exclude，但可单独覆盖 - 推荐组合写法（放在
.vscode/settings.json）：
{
"files.exclude": {
"**/.git": true,
"dist/**": true
},
"search.exclude": {
"**/node_modules": true,
"**/*.log": true,
"**/coverage/**": true,
"**/build/**": true
}
}
注意：search.exclude 支持 **/*.log 这类通配，而 files.exclude 对文件后缀通配支持较弱，建议优先用 search.exclude 控制搜索范围。
大项目必须关掉 files.watcherExclude
即便搜索和显示都排除了，VSCode 默认仍会用系统 inotify（Linux/macOS）或 FindFirstChangeNotification（Windows）监听所有子目录变更——包括 node_modules 下数万文件。这会导致 CPU 占用高、响应卡顿，尤其在 WSL 或远程开发时更明显。
-
files.watcherExclude是唯一能真正关闭文件监视的配置项 - 它不接受 glob 的
**，只支持前缀匹配，例如："**/node_modules/**"❌，应写为："**/node_modules/**": true✅（VSCode 内部会识别这种写法） - 务必同时排除常见构建输出目录：
"**/dist/**"、"**/out/**"、"**/target/**"
排除规则冲突时以 search.exclude 为准
如果某路径既在 files.exclude 里，又在 search.exclude 里，VSCode 会合并处理；但如果出现矛盾（比如一个包含、一个排除），最终行为由 search.exclude 主导——因为搜索引擎层更底层，且不依赖 UI 显示逻辑。
- 典型冲突场景：你在
files.exclude里写了"src/test/**"（隐藏测试目录），但想保留测试文件参与搜索 → 必须在search.exclude中显式删掉或覆盖该条目 - 验证是否生效：打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，在 Console 中搜search，能看到实际参与搜索的文件路径列表 - 远程开发（SSH/WSL）下，
files.watcherExclude尤其关键——否则本地 VSCode 会尝试同步监听远端整个node_modules，极易超时断连
