Webpack中loader的exclude与include哪个性能优化效果更好？

在Webpack构建流程里，module.rules配置中的loader负责把各类资源转换成可打包的模块。面对成千上万的文件，exclude和include这两个字段直接决定了loader扫描的范围。理解它们背后的匹配逻辑，是做构建提速的前提。

匹配机制与执行原理差异

Webpack在处理每个文件时，会逐个检查rule中的条件。include表示只有匹配该条件的文件才会应用loader，属于白名单机制；exclude则表示匹配该条件的文件被排除，属于黑名单机制。从内部实现看，Webpack使用webpack/lib/RuleSet来解析这些条件，当文件绝对路径进入模块工厂后，会先被RuleSet.normalizeRules处理过的test、include、exclude做比对。

如果配置了include，Webpack在遍历文件阶段就能快速判断路径是否落在指定目录内，不在其中的直接跳过loader函数调用。而exclude通常是在更广泛的test命中后，再过滤掉特定路径。这意味着当test范围很宽（例如匹配所有js）且未设include时，即便有exclude，loader的前期路径解析与test正则执行依然会发生。底层Condition匹配逻辑中，目录型include多用绝对路径startsWith判断，开销极低；exclude常写为node_modules正则，每次都要跑RegExp.exec，文件量巨大时累积成本不可忽视。

下面这段配置展示了两种写法在RuleSet中的直观差异。白名单方式让loader只关心src，黑名单方式则先接收全部js再剔除。二者在小型项目中感知不强，但仓库文件过万时，前者的条件短路优势就会显现。

// 使用include白名单
module.exports = {
  module: {
    rules: [
      {
        test: /.js$/,
        include: /src/,
        use: 'babel-loader'
      }
    ]
  }
};

// 使用exclude黑名单
module.exports = {
  module: {
    rules: [
      {
        test: /.js$/,
        exclude: /node_modules/,
        use: 'babel-loader'
      }
    ]
  }
};

大型项目中的实测性能对比

我们在一个包含约两万五千个js文件的业务中台仓库做对比。基线配置仅用test匹配js且不加任何范围限制，平均构建时间稳定在38秒。改用exclude: /node_modules/后，因为node_modules本身不在项目源码树被test扫到的频率取决于resolve配置，实际只降至36秒，提升微弱，因为大量src内遗留的旧文件仍被babel-loader解析。

当切换为include: path.resolve(__dirname, 'src')并配合test，构建时间掉到21秒。原因在于Webpack在loader调度前就用目录前缀排除了非src文件，连test正则都少执行了上万次。更进一步，把include精确到src/pages等真实含需编译代码的子目录，时间可压到18秒。这说明exclude适合做安全兜底，include才是精准提速的刀刃。

需要注意，include若写得过于细碎，例如对每个子包写多个绝对路径数组，会增加RuleSet条件数组遍历次数。推荐用单个父级目录配合test里的业务后缀约束，既减少条件数，又控制命中面。下表列出三种策略在同一CI机器上的表现：

配置选型与常见误区

不少团队误以为exclude写node_modules就足够优化，这忽略了monorepo里大量内部包位于packages下、却被test广泛命中的情况。此时exclude没覆盖这些路径，loader依旧全员执行。正确做法是在monorepo根配置里用include指向真正需要转译的源码包，同时对第三方esm包单独设rule处理。

另一个误区是同时写include和exclude且范围重叠，导致RuleSet条件冲突或优先级难以直观判断。Webpack文档明确二者是独立条件，都满足时才应用loader；若include指向src、exclude也指向src子目录，结果只剩未被exclude的部分，这种隐式减法容易在后续目录调整时引发构建遗漏。建议保持单一维度，要么纯include规划白名单，要么纯exclude做依赖隔离。

在动态import较多的项目，还可以结合resolve.alias把稳定库映射到预编译包，再从include中移除对应目录，进一步缩小loader面。下面代码展示了一个兼顾第三方与业务的清晰写法，将应用代码和本地组件库纳入编译，其余一律不进babel。

const path = require('path');

module.exports = {
  module: {
    rules: [
      {
        test: /.js$/,
        include: [
          path.resolve(__dirname, 'src'),
          path.resolve(__dirname, 'components')
        ],
        use: {
          loader: 'babel-loader',
          options: { cacheDirectory: true }
        }
      }
    ]
  },
  resolve: {
    alias: {
      'stable-lib': path.resolve(__dirname, 'vendor/stable-lib.es5.js')
    }
  }
};

总结来看，exclude是防御性配置，include是进攻性优化。在文件规模增长后，用include圈定核心编译区带来的性能收益明显大于exclude过滤。实际落地时，应以include为主、exclude为辅，并定期用webpack --profile审视loader耗时分布，防止范围配置随目录变迁而失效。

webpackloader_excludeloader_include修改时间：2026-08-15 15:45:33