为什么Vendor分离后vendor.js反而比main.js还大？

迷人的志信提问于 2026-02-09 21:58:29 阅读 190

优化

在用Webpack做Vendor分离时，配置了splitChunks按需拆分第三方包，但生成的vendor.chunk.js居然比app代码还大两倍，加载反而更慢了。按照文档设置了cacheGroups和minSize，尝试过把vendor组的priority调高，但打包结果完全没变化：


optimization: {
  splitChunks: {
    cacheGroups: {
      vendor: {
        test: /node_modules/,
        priority: 20,
        minSize: 10000
      }
    }
  }
}

检查过入口文件确实只引入了几个小库，为什么打包出来的vendor chunk反而包含了大量未使用的依赖？

我来解答赞 6 收藏

反馈

2 条解答

欧阳博泽 Lv1

这问题挺常见的，其实跟Webpack的打包机制有关。你现在的配置虽然把node_modules里的东西都打进vendor了，但可能有些间接依赖也被打包进去了，导致vendor变得特别大。

咱们得调整一下splitChunks的配置，关键是用好chunks和enforce这两个选项。试试这样改：

optimization: {

  splitChunks: {

    cacheGroups: {

      vendor: {

        test: /node_modules/,

        name: 'vendors',

        chunks: 'all',

        enforce: true,

        priority: 20

      }

    }

  }

}

这里重点是加了enforce: true，它会强制按照你的规则来拆分，忽略默认的minSize限制。还有chunks: 'all'也很关键，确保同步异步模块都能正确分离。

另外，建议检查下项目里是不是有动态导入或者隐式的依赖引用，比如某些库可能在运行时才加载依赖，这种情况下Webpack会把这些也打进vendor里。

对了，还有一点容易被忽略，看看你的babel-loader或者其他loader有没有正确设置exclude，避免把node_modules里的东西重复处理了。像WP里面经常遇到类似情况，明明没直接引用某个库，但因为其他插件依赖它，结果被打包进去了。

最后提醒一句，现在这年头做代码分离，与其纠结vendor大小，不如考虑按页面或功能来做代码拆分，这样更实用些。

2026-02-18 09:13

Prog.子硕 Lv1

你这个情况我遇到过好几次，根本问题出在splitChunks的默认行为上。虽然你写了minSize，但Webpack默认的minSize是30000，而你设成10000其实还是太小了，加上没有指定chunks类型，导致它把动态加载和异步模块全塞进vendor里了。

更关键的是test匹配了所有node_modules，但没排除那些其实不该打进vendor的大包，比如有些项目会不小心把babel runtime或者polyfill重复打进去了。

可以优化成这样：

optimization: {

  splitChunks: {

    chunks: 'all',

    cacheGroups: {

      vendor: {

        test: /[\/]node_modules[\/]/,

        name: 'vendors',

        priority: 20,

        enforce: true,

        minSize: 50000,

        minChunks: 1

      }

    }

  }

}

先把minSize提到5万以上，避免拆出太多零碎chunk拖慢加载。enforce强制生效cacheGroups规则，不然其他默认组可能覆盖你的配置。chunks设成all确保异步模块也参与拆分。

然后用webpack-bundle-analyzer跑一遍分析，十有八九会发现某个大包被重复引用了，比如lodash全量引入或者moment带了全部语言包。这种时候再针对性地用normalModuleReplacementPlugin做替换，比瞎调splitChunks参数有用多了。

说白了splitChunks只是拆包工具，真正要瘦身还得靠分析+精准剔除。

2026-02-09 22:01