本文详细解析 Webpack 中 SplitChunksPlugin 的核心配置参数，涵盖 chunks、minSize、maxAsyncRequests 等关键选项的作用与默认值。通过实例讲解 reuseExistingChunk 机制及 cacheGroup 分组策略，帮助开发者理解如何优化打包结果，实现高效的代码分割与缓存复用。
Webpack SplitChunksPlugin 配置参数详解
代码分割技术本身与 Webpack 并无直接关联，但由于借助 Webpack 能够极为便捷地实现代码分割功能，因此在讨论代码分割方案时，大家往往首先联想到使用 Webpack 进行实现。
在 Webpack 构建体系中，SplitChunksPlugin 插件负责执行代码分割任务。鉴于 SplitChunksPlugin 包含的配置参数繁多且复杂，下文将对这些关键配置参数进行系统梳理与解析。
以下是 Webpack 官方文档中给出的默认配置参数示例：
module.exports = {
//...
optimization: {
splitChunks: {
chunks: 'async', // 代码分割时对异步代码生效，all：所有代码有效，inital：同步代码有效
minSize: 30000, // 代码分割最小的模块大小，引入的模块大于 30000B 才做代码分割
maxSize: 0, // 代码分割最大的模块大小，大于这个值要进行代码分割，一般使用默认值
minChunks: 1, // 引入的次数大于等于1时才进行代码分割
maxAsyncRequests: 6, // 最大的异步请求数量,也就是同时加载的模块最大模块数量
maxInitialRequests: 4, // 入口文件做代码分割最多分成 4 个 js 文件
automaticNameDelimiter: '~', // 文件生成时的连接符
automaticNameMaxLength: 30, // 自动生成的文件名的最大长度
cacheGroups: {
vendors: {
test: /[\\/]node_modules[\\/]/, // 位于node_modules中的模块做代码分割
priority: -10 // 根据优先级决定打包到哪个组里，例如一个 node_modules 中的模块进行代码
}, // 分割，，既满足 vendors，又满足 default，那么根据优先级会打包到 vendors 组中。
default: { // 没有 test 表明所有的模块都能进入 default 组，但是注意它的优先级较低。
priority: -20, // 根据优先级决定打包到哪个组里,打包到优先级高的组里。
reuseExistingChunk: true // //如果一个模块已经被打包过了,那么再打包时就忽略这个上模块
}
}
}
}
};
针对上述配置，补充说明几点关键细节：
在分组配置中，可以手动指定打包后输出文件的名称。例如，在 vendor 分组中设置 filename = "vendor.js" 后，该分组下所有打包生成的文件名称将统一为 vendor.js。
接下来通过 reuseExistingChunk 的具体实例进行讲解：
// a.js
import b from './b';
// index.js
import a from './a';
import b from './b';
在上述代码逻辑中，index.js 在执行 import a from './a' 语句时引入了 a 模块。由于 a 模块内部依赖了 b 模块，因此构建过程中也会自动引入 b 模块。随后当 index.js 再次执行 import b from './b' 时，因为 b 模块此前已被打包处理，Webpack 会忽略此次重复引入。这正是 reuseExistingChunk: true 配置项的核心作用，即复用已存在的代码块。
那么，如何将两个不同的模块打包合并到同一个文件中呢？
这可以通过 cacheGroup 配置来实现。假设存在 module1 和 module2 两个模块，且它们均符合 vendor 分组的条件。在进行代码分割时，Webpack 会先将 module1 放入 CacheGroup，随后将 module2 也加入该 CacheGroup，最后将两者合并至 vender 组，最终生成 vender.js 文件。
至此，关于 Webpack 中 SplitChunksPlugin 配置参数的详细解析已介绍完毕。如需了解更多关于 Webpack SplitChunksPlugin 的相关内容，建议搜索本站历史文章或继续阅读后续相关文章，希望大家今后能多多支持本站！