search.exclude 通过持久化 glob 规则精准排除搜索路径，提升速度与准确性；它作用于文件候选集生成阶段，支持 通配符，需区分 files.exclude，典型配置如 "/node_modules": true，团队应提交至 git 并注意 monorepo 和临时调试需求。

直接在 search.exclude 里加几行 glob 规则，就能让搜索结果干净、快、准——不用手动翻页，也不用反复删干扰项。

为什么 search.exclude 比临时输入 -exclude: 更可靠

临时加 -exclude:node_modules 看似方便，但每次打开新搜索框都要重输，且无法被团队共享或版本控制。而 search.exclude 是持久化配置，写一次，全项目生效，还自动继承到所有新打开的搜索面板中。

• 它作用于 VSCode 搜索引擎的「文件候选集生成阶段」，未匹配的路径根本不会被读取，性能提升是实打实的
• 支持通配符 **，能穿透任意嵌套层级（比如 packages/*/node_modules）
• 和 files.exclude 分开管理：前者只影响搜索，后者还隐藏侧边栏文件，别混用

search.exclude 的典型配置项怎么写才不踩坑

规则写错会导致目录没排除成功，甚至误排除源码。关键看三点：路径语法、布尔值、是否带前导 /。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• "**/node_modules": true ✅ 正确：匹配所有层级下的 node_modules 目录
• "node_modules": true ❌ 错误：只匹配项目根目录下的同名目录，漏掉 packages/foo/node_modules
• "**/dist/**": true ✅ 可以，但冗余；"**/dist": true 就够了（VSCode 自动递归跳过整个目录）
• "**/*.log": true ✅ 排除所有日志文件；"*.log": true ❌ 只排除根目录下的日志

哪些目录必须加进 search.exclude（按优先级）

不是所有“看起来大”的目录都该排除——得看它是否含可编辑源码。以下是最常被误搜、最值得优先屏蔽的几类：

• "**/node_modules": true —— 第三方依赖，99% 场景下你不想改它
• "**/dist": true、"**/build": true、"**/out": true —— 构建产物，每次 npm run build 就变，搜到也白改
• "**/coverage": true —— 测试覆盖率报告，纯生成内容
• "**/*.min.js": true、"**/*.bundle.js": true —— 压缩/打包后文件，无调试价值
• "**/logs": true、"**/*.log": true —— 日志文件体积大、内容动态，毫无搜索必要

团队协作时怎么确保 everyone 用同一套排除规则

把 .vscode/settings.json 提交进 Git，比口头提醒或文档更有效。但要注意两点：

• 只放 search.exclude 和 files.exclude 这类与项目结构强相关的配置；别塞进 "editor.tabSize": 2 这种个人偏好项
• 如果项目有多个子包（如 monorepo），检查 **/node_modules 是否真能覆盖所有位置——有些工具（pnpm）会把依赖放在顶层 node_modules，此时还需加 "node_modules": true
• CI 或远程开发环境（如 GitHub Codespaces）默认不读取 .vscode，需额外通过 devcontainer.json 注入或引导用户手动启用

真正容易被忽略的是：排除规则一旦生效，就再也搜不到那些路径下的任何内容——包括你某天突然想查某个 node_modules 里的报错堆栈源码时，得临时注释掉配置再重试。所以别图省事全盘 exclude，留一两个关键路径备用。