VSCode设置文件排外：在搜索结果中过滤node_modules等目录

VSCode全局搜索需配置search.exclude而非files.exclude；正确写法为"**/node_modules": true，且须置于项目级.vscode/settings.json中。

很多开发者可能都踩过这个坑：明明已经在files.exclude里屏蔽了node_modules，为什么用Ctrl+Shift+F全局搜索时，结果里还是堆满了依赖库里的文件？

原因其实很简单：files.exclude只管“眼不见”，它只让目录在侧边栏资源管理器里消失，对全局搜索功能完全不起作用。想让搜索结果干净，必须请出真正的主角——search.exclude。

search.exclude 才是搜索过滤的唯一生效项

这两个配置项名字相似，位置也挨着，但职责范围泾渭分明。search.exclude专门负责过滤搜索结果，而files.exclude只负责管理文件树的显示。把规则写错地方，等于白忙活一场。

配置必须明确写在项目级的.vscode/settings.json文件里。如果图省事写在用户全局配置里，换个项目或者重装编辑器，设置就失效了。另一个高频错误是路径写法："node_modules": true或者"node_modules/**": true都是不完整的，缺少了关键的**/前缀，导致嵌套在深层子目录下的node_modules（比如src/lib/node_modules）依然会被搜到。

正确的写法应该是这样一组清晰的规则：

• "**/node_modules": true：递归匹配项目里任何层级的node_modules目录。
• "**/dist": true：排除所有构建产出的目录。
• "**/*.min.js": true：跳过那些压缩过的JS文件，避免在压缩代码里搜到无关内容。
• 记住，search.exclude只识别glob模式，别往里塞正则表达式符号。

多根工作区下，每个文件夹要单独配

如果你打开的是一个多根工作区（Monorepo项目里很常见），情况会复杂一些。search.exclude的配置是按工作区内的每个根文件夹独立生效的，根目录下的设置不会自动继承到所有子文件夹。

这就容易导致几个典型的踩坑场景：

• 你想在主项目里屏蔽packages/legacy，但又需要经常搜索packages/utils。这时就必须在对应子文件夹的.vscode/settings.json里单独配置search.exclude。
• 使用了绝对路径（如/Users/name/project/packages/legacy/**），一旦换台机器或者移动项目，配置立刻失效。最佳实践是始终使用相对路径加**/。
• 规则写得过于宽泛，或者堆砌了大量规则。VSCode在每次执行搜索前都要逐条匹配这些模式，反而可能拖慢搜索速度。

临时排除比永久配置更灵活

当然，不是所有过滤都需要写入配置文件。VSCode的搜索面板本身就提供了一个非常灵活的临时过滤功能。

打开搜索面板（Ctrl+Shift+F），留意右下角那个「files to exclude」输入框。你可以直接在里面填入node_modules/**,dist/**,*.map，用逗号分隔多个模式，即时生效。这个输入框的优先级甚至高于search.exclude里的配置，非常适合临时性的调试或一次性搜索任务。

使用时注意几个细节：

• 这里填写的模式也必须是glob格式，并且建议带上**/前缀以确保匹配所有层级。
• 勾选下方的「Include ignored files」选项，可以临时取消所有排除规则，方便你验证之前的过滤是否真的生效了。
• 如果一些插件（比如GitLens）的视图里仍然显示了node_modules的文件，别慌，这通常是因为这些插件的视图渲染绕过了search.exclude机制，属于正常现象。

为什么有时候排除了还是搜到 dist 里的文件？

如果严格按照上面说的做了，但构建目录dist里的文件还是出现在搜索结果里，问题可能出在以下几个地方：

• 首先确认，配置确实写在了项目内的.vscode/settings.json，而不是用户的全局配置文件里。
• 再次核对路径写法，必须是"**/dist": true，而不是"dist": true。
• 检查搜索面板上方的「files to include」输入框是否被误填了内容。这个框的作用是“强制只搜这里面的”，它的优先级最高，如果里面写了dist，就会覆盖掉所有的排除逻辑。
• 如果修改了配置但没生效，尝试重启VSCode或者执行“重新加载窗口”的命令，某些旧版本对search.exclude的修改不支持热更新。

说到底，配置的学问不在于死记硬背，而在于验证。最可靠的方法就是：配完之后，立刻去搜一个你确信只存在于node_modules或dist里的特定字符串（比如webpackBootstrap），看看结果是否干净。这比反复阅读文档要直观得多。