如何使用Webpack 5的SplitChunksPlugin减少chunk间的模块重复

核心设计理念 #

SplitChunksPlugin 的设计目标不是将模块重复率降到0，它的核心逻辑是在「打包体积收益、额外HTTP请求成本、长期缓存命中率、构建性能」四个维度做平衡，只有抽离公共代码的综合收益大于成本时，才会执行抽离操作。

25KB模块未被抽离的常见场景 #

• 缓存组匹配规则不满足：默认配置下SplitChunks只处理异步加载的chunk，如果引用该模块的15个chunk是初始同步chunk，不会命中默认抽离规则，需要将对应缓存组的chunks参数设为all才能覆盖同步+异步场景。
• 大小阈值计算逻辑不匹配：你观测到的25KB是压缩、tree-shake后的最终产物大小，而SplitChunks的minSize默认基于未压缩、未转换的原始模块体积计算，如果该模块原始体积小于你配置的minSize阈值，就不会被抽离。
• 强制抽离开关未开启：默认enforce: false的情况下，就算模块满足minChunks、minSize要求，Webpack还会做额外的收益校验：如果抽离该模块新增的请求开销大于体积减少带来的收益，会主动放弃抽离，只有将enforce设为true才会忽略收益校验强制抽离。
• 模块被识别为不同实例：如果你的项目是monorepo、或者存在依赖重复安装的情况，同一个npm包可能存在多份拷贝，对应不同的磁盘路径，Webpack会将其判定为完全不同的模块，不会执行公共抽离。
• 缓存组优先级冲突：如果模块同时匹配多个缓存组，会被优先级更高的缓存组处理，若高优先级缓存组没有命中抽离规则，低优先级缓存组也不会再处理该模块。

排查调试步骤 #

• 首先确认重复模块的唯一性：使用webpack-bundle-analyzer或者webpack --stats detailed输出打包详情，校验重复出现的模块的完整磁盘路径是否完全一致，若路径不同先做依赖对齐处理（比如monorepo下配置resolve.alias指向根目录node_modules、统一依赖版本）。
• 临时配置强抽离规则验证：给公共缓存组配置如下参数，观察重复模块是否被抽离：

cacheGroups: {
  common: {
    chunks: 'all',
    minChunks: 2,
    minSize: 0,
    priority: 10,
    enforce: true
  }
}

如果此时重复模块消失，再逐步调整minSize、移除enforce参数，找到体积和请求数的平衡点。

• 源码调试：直接在node_modules/webpack/lib/optimize/SplitChunksPlugin.js的processModule方法中打断点，观测目标模块的引用计数、缓存组匹配结果，即可定位未被抽离的具体原因。

内容的提问来源于stack exchange，提问作者Scott Cameron