为何在Webpack 4中设置minChunks会导致cacheGroup构建失败？

这情况我之前也碰到过——设置minChunks后构建莫名卡住还没错误提示，大概率是配置逻辑里的隐性问题，我帮你梳理几个核心排查方向：

1. 先确认minChunks的取值逻辑是否踩坑 #

minChunks是用来指定模块被引用多少次才会被打包到这个cacheGroup，它支持数字或函数两种写法，很容易在这里出错：

• 如果是数字值，比如设成minChunks: 3，但你的项目里根本没有模块被引用3次以上，那这个cacheGroup不会生成任何chunk，但一般不会导致构建卡住；
• 如果是函数写法，一定要确保返回值是布尔值，且不要在函数里触发模块遍历的死循环。比如错误地在函数里递归调用模块分析，就会让Webpack进程卡死。

给你一个靠谱的函数写法参考：

minChunks: (module, count) => {
  // 只提取被引用至少2次的node_modules模块
  return module.resource && /node_modules/.test(module.resource) && count >= 2;
}

2. 检查cacheGroup的其他配置是否冲突 #

比如你有没有设置test规则太严格，导致没有模块能匹配到这个cacheGroup？或者priority优先级设置得不合理，让其他cacheGroup先把模块抢走了？

贴一个完整的splitChunks配置示例，你可以对照着检查自己的配置：

optimization: {
  splitChunks: {
    chunks: 'all', // 单入口项目要拆同步chunk必须设为'all'或'initial'
    cacheGroups: {
      vendor: {
        test: /[\\/]node_modules[\\/]/,
        name: 'vendors',
        minChunks: 1,
        priority: -10 // 优先级越高越先匹配
      },
      common: {
        name: 'common',
        minChunks: 2,
        chunks: 'all',
        priority: -20,
        reuseExistingChunk: true // 开启后会复用已有的chunk，避免重复打包
      }
    }
  }
}

特别注意reuseExistingChunk: true，没开的话可能会导致重复打包相同模块，也可能引发构建异常。

3. 排查是否是循环引用导致的构建卡住 #

当设置minChunks后，Webpack会更深入地分析模块引用关系，如果你的项目里存在循环引用，某些场景下会让Webpack的依赖分析进程卡住，而且不会抛出明显错误。

你可以先临时注释掉minChunks配置，看构建是否正常。如果正常，再逐步排查哪些模块的引用次数达到了minChunks阈值，然后检查这些模块是否有循环引用的情况。

4. 开启Webpack详细日志定位卡点 #

既然没有错误提示，那就让Webpack输出更详细的日志，看看卡在哪个环节了。在构建命令里加上--progress --verbose参数：

webpack --config webpack.prod.js --progress --verbose

这样能看到构建的每一步进度，精准定位到是处理哪个模块或cacheGroup时卡住的，方便进一步排查。

最后补充：单入口项目的splitChunks注意点 #

你的entry是单入口build: './src/main.js'，splitChunks默认只对异步chunk生效。如果要拆分同步模块，必须把splitChunks.chunks设为'all'或者'initial'，不然设置minChunks也不会有效果。虽然这一般不会导致构建卡住，但还是建议确认一下。

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