一个让人头疼的场景：项目里配了 babel-loader 处理所有 .js 文件，命令行却刷出一堆来自 node_modules 的语法错误；或者明明只是加了 less-loader，打包时间却直接翻倍。问题出在哪？多半是 loader 的 test 正则把不该管的文件也圈了进来。要解决这个问题，我们先得理解 Webpack 在匹配 loader 时的真实逻辑。
test 正则的作用域不只是文件后缀
很多配置习惯性写 test: /.js$/，想当然地以为只有 src 下的文件会被命中。实际上，test 检查的是模块的完整请求路径，而不仅仅是从 context 开始的相对路径。当你 import 一个位于 node_modules 里的包时，Webpack 会解析到类似 /Users/me/project/node_modules/some-lib/index.js 这样的绝对路径，然后拿着这个路径去匹配 test 正则。因此 /.js$/ 很自然地就会匹配到 node_modules 下的 JavaScript 文件，导致应用的 loader 对第三方库也执行一遍。
更深一层，test 匹配的目标其实是模块的 resourcePath。无论是 js、ts、css 还是图片，只要路径字符串与正则匹配，loader 就会激活。而且有些 loader 还可以通过 matchResource 影响匹配对象，但那是比较高级的玩法，日常配置极少涉及。通常我们遇到的“误触发”都是因为在正则里没有区分项目源码与依赖目录。
这里需要纠正一个认知：test 并不享有“默认忽略 node_modules”的待遇。Webpack 自带的模块解析规则里，对 node_modules 的跳过程序主要是针对 resolve.modules 的查找优化，而非 loader 匹配。也就是说，就算你在 resolve 里把 node_modules 配置为模块目录，test 正则依然会去检查那些最终被解析进来的文件路径。
为什么必须把 node_modules 排除在外
性能是首要原因。每个 loader 的执行都有开销，babel 转译、postcss 处理甚至是简单的 raw-loader，如果对数百个 node_modules 模块重复进行，累积的耗时非常可观。开发模式下 hot reload 会变慢，生产构建时间拉长。尤其在 monorepo 或大型项目里，node_modules 的体积动辄上 GB，文件数量上万，避免不必要的遍历是基础优化。
其次，业务 loader 的预设往往不适用于第三方库。比如 babel 的 preset-env 可能包含了一些对浏览器最新的 polyfill 方案，而库的作者早已做了转译或使用了老语法，二次处理反而可能引入重复的 helper 或导致代码膨胀。更麻烦的是，一些依赖内部使用了 class 私有属性、装饰器等处于 stage 阶段的语法，你本地的 babel 配置可能不支持，直接报错，而这完全不是项目代码的问题。
再者，安全与可维护性也得考虑。你不希望自己的 style-loader、css-loader 去改写 antd 的样式文件，打乱组件的默认外观。虽然有时为了定制主题不得不覆盖，但那应该通过 less/scss 变量或专门的覆盖文件来实现，而不是用全局 loader 直接浸染 node_modules。划定清晰的边界能让配置意图更明确，减少诡异 bug。
正确组合 test、include 与 exclude
最直接的做法是用 exclude: /node_modules/。在 Webpack 的 loader 规则里，exclude 优先级高于 test，而且它检查的也是 resourcePath。写法如下：
{
test: /.js$/,
exclude: /node_modules/,
use: 'babel-loader'
}
这能确保只有 node_modules 以外的 .js 文件才会被 babel-loader 处理。如果你的项目存在多个依赖目录（比如 pnpm 的 .pnpm 或 yarn 的 .yarn），简单的 /node_modules/ 可能失效，此时可以使用函数形式的 exclude，更灵活地判断路径：
{
test: /.js$/,
exclude: (modulePath) => {
// 返回 true 表示排除
return /node_modules/.test(modulePath) || /.pnpm/.test(modulePath);
},
use: 'babel-loader'
}
与 exclude 相对的是 include，二者功能互斥，一般只用一个。include 可以直接指定源码目录，例如 include: path.resolve(__dirname, 'src')。这样即使 test 正则会匹配到其它路径，loader 也只对 src 内的文件生效。include 通常是更稳妥的选择，因为它显式地“白名单”了范围，不会受未来新增目录的影响。
注意 include 和 exclude 都可以是正则、字符串、数组或函数。对于复杂的 monorepo 结构，使用函数能精确控制每个模块的归属。例如，你想让 loader 处理 packages 下的所有源码，但避开其中的 legacy 文件夹：
{
test: /.tsx?$/,
include: (modulePath) => {
// 只对 packages 目录下且不包含 legacy 的路径返回 true
return /packages/.test(modulePath) && !/legacy/.test(modulePath);
},
use: 'ts-loader'
}
当 test、include、exclude 同时存在时，Webpack 的判断顺序是：先检查 test 是否匹配，若不匹配则直接跳过；然后检查 include，若有 include 则仅当路径满足 include 时才继续，否则终止；最后检查 exclude，若满足 exclude 则终止。理解了这套流程，就能组合出非常精细的匹配逻辑。
警惕一些易踩坑的正则写法
常见错误是把 node_modules 的排除直接糅合在 test 正则里，比如 test: /^(?!.*node_modules).*.js$/。虽然也能工作，但可读性差，而且 test 正则会在每个模块上都执行一遍较复杂的断言，性能不如直接用 exclude。更何况这种写法需要开发者自己对正则负责，一旦拼接失误，可能漏掉真正的目标文件，排查起来很费劲。
另一个容易忽视的点是路径分隔符。Windows 下路径使用反斜杠 ，而正则里 需要转义，导致 /node_modules/ 在 Windows 上可能匹配不到。Webpack 内部会把路径统一为 POSIX 风格的斜杠，所以直接用 /node_modules/ 是安全的。但是自行拼接路径符号时要注意平台差异，建议始终使用 path.normalize 或者直接用 / 来写正则，因为 Webpack 在比较前已经进行了标准化处理。
还有一种情况是某些 loader 自己提供了 exclude 选项，比如 url-loader 的 limit 之外还可以通过 exclude 跳过特定文件。这是 loader 层面的过滤，与 Webpack 规则的 exclude 不同，但同样能用来排除 node_modules。遇到这种 loader，优先使用规则级别的 exclude 以保证一致性，除非 loader 的选项能提供更高性能（例如在模块解析阶段就可以提前短路）。
最后提醒一下，在 oneOf 规则数组中使用 exclude 时，注意 oneOf 只会应用第一个匹配的规则，如果前面的规则因为 exclude 过宽而漏掉了某些文件，后面的规则不会再检查。因此 oneOf 的排序很重要，应当把最精确的规则放在前面，把通用的兜底规则放在最后。