共计 1682 个字符，预计需要花费 5 分钟才能阅读完成。
optimization.splitChunks
cacheGroups
个人感觉 splitChunks 中除了 cacheGroup 之外的配置是用来作代码分割的，而 cacheGroup 是作为模块合并的配置项。cacheGroup 内配置优先级高于外面配置，可以理解为先进行分割再进行合并，分割的代码放到哪个缓存组的块中，由优先级决定。
可进行如下配置：
splitChunks:{
cacheGroups: {
common:{
chunks: 'initial',
name:'testCommon', // 打包后的文件名
minSize: 0,
minChunks: 2 // 重复 2 次才能打包到此模块
},
vendor: {
priority: 1, // 优先级配置，优先匹配优先级更高的规则，不设置的规则优先级默认为 0
test: /node_modules/, // 匹配对应文件
chunks: 'initial',
name:'testVendor',
minSize: 0,
minChunks: 1
}
}
}
除了 test, priority 和 reuseExistingChunk 只能卸载 cacheGroups 里，其他属性都能直接写在 splitChunks 下。
chunks
前一步配置中提到 chunks 一般用 initial 打包规则，chunks 可配置的参数有：all, async 和 initial 三种。具体区别详见：
https://juejin.im/post/5c08fe7d6fb9a04a0d56a702
总结一下：
initial: 对于匹配文件，非动态模块打包进该 vendor, 动态模块优化打包
async: 对于匹配文件，动态模块打包进该 vendor, 非动态模块不进行优化打包
all: 匹配文件无论是否动态模块，都打包进该 vendor
webpack4 的默认配置中，splitChunks.chunks 默认是 async, 因为 webpack 更希望将代码中异步引入的部分作为独立模块进行打包，异步的部分在需要时引入，这种懒加载的方式更能提升页面性能。
注：import() 可动态加载模块，返回一个 Promise。
minSize
当模块大于 minSize 时，进行代码分割
maxSize
当模块大于 maxSize 时，尝试将该模块拆分，如设置 maxSize 为 50*1024，代码中引入了 jQuery,jQuery 模块大于 50kb, 于是尝试将 jQuery 拆分（只是尝试，不一定真能拆分成功）
maxAsyncRequests
同时加载的模块数，若代码分割设置的是一个库分割成一个模块，打开某个页面时同时需要加载 10 个库，设置 maxAsyncRequests：5，只会将那 10 个库分割成 5 个模块
maxInitialRequests
最大初始化加载次数，入口文件可以并行加载的最大文件数量。
maxInitialRequest 和 maxAsyncRequests 中的 ’initial’ 和 ’async’ 代表的意思和 chunks 配置中的 ’initial’ 和 ’async’ 一样，maxAsyncRequests 代表懒加载时最多只能同时引入多少个模块，maxInitialRequests 代表非懒加载时最多能同时引入多少模块。
假设 maxInitialRequests 设为 3，有文件 a.js 中，使用了大量 import xx from ‘xx’,a.js 依赖的这些非动态加载的模块，最多只会被打包成 3 个模块。
可参考：
https://ymbo.github.io/2018/05/21/webpack 配置代码分割 /#%E4%B8%89%E3%80%81%E7%96%91%E9%9A%BE%E9%85%8D%E7%BD%AE%E9%A1%B9
automaticNameDelimiter
打包的 chunk 名字连接符，如设为 ’-‘, 生成的 chunk 文件名为 chunk-name.js
name
是否以 cacheGroups 中的 filename 作为文件名
reuseExistingChunk
重复使用已经存在的块，若某个模块在之前已经被打包过了，后面打包时再遇到这个模块就直接使用之前打包的模块
