Webpack 的 optimization 字段决定了打包结果在体积、加载效率与缓存友好度上的表现。很多项目明明开启了 production 模式，产物体积却依旧偏大，很大一部分原因是 optimization 中的细节没有被充分利用。它并不只是控制压缩的开关，还会影响模块合并策略、代码分包方式、Tree Shaking 是否生效以及文件名的稳定性。理解这些配置之间的联动关系，比单纯记住某个参数更重要。
一、从 minimize 与 minimizer 说起：压缩不只是开关
optimization.minimize 是控制压缩行为的顶层开关。Webpack 在 mode 为 production 时会自动将其置为 true，开发模式下默认关闭。但开启 minimize 之后，Webpack 5 内部会使用 TerserPlugin 对 JavaScript 进行压缩，默认配置已经能应对多数场景。真正需要调整的是 minimizer 数组，因为该数组一旦被用户显式赋值，就会覆盖默认压缩器，而不是追加。
例如在 webpack.config.js 中，可以显式引入 TerserPlugin 并调整其参数。这样做的收益通常来自并行压缩、缓存以及去除注释等细节。示例如下：
const TerserPlugin = require('terser-webpack-plugin');
module.exports = {
mode: 'production',
optimization: {
minimize: true,
minimizer: [
new TerserPlugin({
parallel: true,
terserOptions: {
compress: {
drop_console: false,
},
format: {
comments: false,
},
},
extractComments: false,
}),
],
},
};
这里把 parallel 打开，TerserPlugin 会利用多进程并行压缩文件，在大型项目中能明显缩短构建时间。drop_console 默认不开启，因为生产环境是否保留 console 取决于业务需求，不要盲目删除。另一个常被忽略的点是 extractComments，它设置为 false 可以避免生成独立的 LICENSE 文件，减少部署文件数量。如果还需要压缩 CSS，可以配合 css-minimizer-webpack-plugin，并把它也写进 minimizer 数组，但要注意此时 JavaScript 和 CSS 的压缩器需要同时存在，否则覆盖默认的 TerserPlugin 会导致 JS 不再被压缩。
二、splitChunks 与 runtimeChunk：把公共代码和运行时拆出来
splitChunks 是 optimization 中最容易影响加载性能的配置。Webpack 默认会把 node_modules 中的公共依赖抽取到单独文件，但默认配置对多入口和动态导入场景并不总是最优。将 chunks 设置为 all 可以让初始加载和异步加载的模块都参与公共代码抽取，从而避免同一个库在不同 chunk 中被重复打包。
下面是一份针对第三方库和业务公共模块的拆分配置：
optimization: {
splitChunks: {
chunks: 'all',
minSize: 20000,
maxSize: 244000,
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
priority: 10,
reuseExistingChunk: true,
},
common: {
minChunks: 2,
priority: 5,
name: 'common',
},
},
},
}
vendor 缓存组通过 test 匹配 node_modules 路径，并将第三方库统一打包成 vendors。minSize 与 maxSize 控制分包体积范围，太小的共享代码不会单独拆出，太大的包则会被拆分。common 组用于业务代码中至少被两个 chunk 引用的模块，减少重复代码。priority 决定了模块同时满足多个缓存组时的归属顺序。
runtimeChunk 的配置经常被忽略。Webpack 的运行时代码负责模块加载与依赖管理，如果它被内联到入口文件中，只要业务代码变化，运行时代码也会跟着变化，进而导致缓存失效。将其设为 single 可以把运行时抽离为单独文件：
optimization: {
runtimeChunk: 'single',
}
这样运行时代码很少变化，配合内容哈希可以让浏览器长期缓存它。对于多入口项目，这个改动尤其关键，否则每个入口都会携带一份不完全相同的运行时逻辑。
三、Tree Shaking 与 sideEffects：让未引用代码消失
Tree Shaking 依赖 ES Module 的静态结构，Webpack 通过 usedExports 标记哪些导出被使用，再由压缩器删除未使用的部分。optimization.usedExports 默认在生产模式下开启，但没有配置 sideEffects 时，Webpack 仍可能保留部分有副作用的代码，导致摇树不彻底。
在 package.json 中声明 sideEffects 可以让打包工具更激进地移除未引用模块。比如一个组件库的 package.json 可以写：
{
"name": "my-component-library",
"sideEffects": [
"*.css",
"./src/polyfill.js"
]
}
如果项目中的代码完全无副作用，可以直接将 sideEffects 设置为 false。副作用指的是模块被导入时会执行的顶层代码，例如修改全局变量、注册事件、引入 CSS 等。CSS 文件通常不导出任何内容，但导入行为本身会产生样式加载效果，因此需要保留在 sideEffects 数组中，避免被误删。JavaScript 的 polyfill 也属于典型副作用模块。
Webpack 端还可以通过 optimization.sideEffects 开启或关闭该优化，但多数情况下保持默认即可。真正影响效果的是你是否使用了 ES Module 语法。CommonJS 的 require 是动态的，无法静态分析导出关系，因此 Tree Shaking 对纯 CommonJS 代码基本无效。如果依赖库同时提供 ESM 与 CommonJS 版本，可以通过 package.json 的 module 字段让 Webpack 优先使用 ESM 版本，从而获得更小的打包结果。
四、moduleIds 与 chunkIds：给长效缓存一个稳定基础
浏览器缓存依赖文件名不变，但 Webpack 给模块和 chunk 分配的 id 如果采用递增数字，新模块插入后原有模块的 id 会整体偏移，导致大量文件内容哈希变化。optimization.moduleIds 和 chunkIds 就是用来解决这个问题的。Webpack 5 推荐使用 deterministic，它会基于模块路径生成短且稳定的 id。
配置如下：
optimization: {
moduleIds: 'deterministic',
chunkIds: 'deterministic',
}
这种模式下，模块 id 不会因新增或删除无关模块而改变，只有真正变化的部分会影响 contenthash。对于使用了长期缓存策略的项目，这是一个成本很低的稳定性提升方案。如果需要对调试更友好，也可以使用 named，但 named 的劣势是文件名会暴露模块路径，且长路径会导致文件名过长。deterministic 在可读性和稳定性之间取得了平衡。
最后还需要注意 optimization.realContentHash 选项。Webpack 5 中它默认开启，会对最终文件内容再做一次哈希计算，避免中间处理步骤影响哈希值。这个选项一般无需手动关闭，但了解它的存在有助于排查哈希不一致的问题。综合上述配置，可以把一个典型的 production optimization 写成：
module.exports = {
mode: 'production',
optimization: {
minimize: true,
minimizer: [
new TerserPlugin({ parallel: true, extractComments: false }),
],
splitChunks: {
chunks: 'all',
},
runtimeChunk: 'single',
usedExports: true,
sideEffects: true,
moduleIds: 'deterministic',
chunkIds: 'deterministic',
realContentHash: true,
},
};
这份配置并不复杂，但它覆盖了压缩、拆包、Tree Shaking 和缓存稳定性几个关键维度。实际项目中再结合具体依赖与多入口结构调整 cacheGroups，就能让 Webpack 的 optimization 发挥出明显效果。
Webpack optimization代码分割Tree Shaking修改时间：2026-09-29 14:52:08