<p>search.exclude 通过持久化 glob 规则精准排除搜索路径，提升速度与准确性；它作用于文件候选集生成阶段，支持 通配符，需区分 files.exclude，典型配置如 "/node_modules": true，团队应提交至 Git 并注意 monorepo 和临时调试需求。</p>
直接在 search.exclude 里加几行 glob 规则，就能让搜索结果干净、快、准——不用手动翻页，也不用反复删干扰项。
为什么 search.exclude 比临时输入 -exclude: 更可靠
临时加 -exclude:node_modules 看似方便，但每次打开新搜索框都要重输，且无法被团队共享或版本控制。而 search.exclude 是持久化配置，写一次，全项目生效，还自动继承到所有新打开的搜索面板中。
- 它作用于 VSCode 搜索引擎的「文件候选集生成阶段」，未匹配的路径根本不会被读取，性能提升是实打实的
- 支持通配符
**，能穿透任意嵌套层级（比如packages/*/node_modules） - 和
files.exclude分开管理：前者只影响搜索，后者还隐藏侧边栏文件，别混用
search.exclude 的典型配置项怎么写才不踩坑
规则写错会导致目录没排除成功，甚至误排除源码。关键看三点：路径语法、布尔值、是否带前导 /。
-
"**/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，留一两个关键路径备用。
