Webpack 5 在发布后，不少配置项的默认行为发生了变化，尤其是在输出文件命名、模块标识生成和代码分割边界方面，整体趋势是让构建结果更精确、更可预测。如果只升级版本而不调整相关参数，往往会遇到哈希值剧烈变化、异步 chunk 文件名不稳定的情况。接下来围绕 Precision 精确度展开。
Precision 精确度的核心：稳定且可预测的模块标识
升级 Webpack 5 之前，很多项目使用 moduleIds: 'hashed' 或默认的数字递增策略来为模块分配内部标识。这种做法在模块数量或顺序发生变化时，会导致大量模块 ID 重新分配，进而引起 chunk 内容变化，即使业务代码只修改了一行。Precision 精确度在模块标识层面的改进，就是用 deterministic 算法替代了旧有的不确定策略。
deterministic 会根据模块的相对路径、内容哈希和项目上下文生成一个稳定且唯一的短标识。只要模块内容不变，它的 ID 就不会因为其他模块的增删而改变。这意味着每次构建产出的 chunk 文件名和内部模块映射更加稳定，缓存失效范围被压缩到最小。对于使用长期缓存策略的应用来说，这种稳定性就是精确度的直接体现。下面的配置展示了如何开启这一能力。
module.exports = {
optimization: {
moduleIds: 'deterministic',
chunkIds: 'deterministic',
},
};
除了模块 ID，chunk ID 的生成同样需要精确控制。Webpack 5 允许将 chunkIds 设置为 deterministic，这样异步 chunk 的名称在多次构建之间也能保持一致。如果不设置，默认情况下 chunk 名称可能基于数字递增，一旦 chunk 数量变化，文件名就会整体漂移，导致 CDN 上大量旧缓存失效。
还需要注意，deterministic 并不是完全消除构建差异，而是把差异限制在真正发生变化的模块内部。比如修改了某个模块的源码，那么只有与该模块关联的 chunk 内容会变，其他未受影响的 chunk 仍然保持原来的哈希值。这正是 Precision 精确度追求的可预测性。
构建输出与哈希精度的关键配置
文件名哈希是浏览器缓存策略的核心。Webpack 5 默认使用 contenthash 来根据文件内容生成哈希，但默认哈希长度可能较长，而且如果没有固定长度或盐值，不同环境下的构建结果会存在细微差异。Precision 精确度允许开发者显式控制哈希函数、摘要长度和盐值，让输出文件名既稳定又安全。
output.hashDigestLength 可以限制哈希摘要的字符长度，例如设置为 8 位，文件名中的哈希部分就不会出现过长或长度不一致的情况。同时 output.hashFunction 支持 xxhash64、md4、sha256 等多种算法，选择更快或更安全的算法取决于项目需求。output.hashSalt 则用于给哈希计算加入额外盐值，防止不同构建环境之间出现意外碰撞。下面的配置示例展示了如何将这些参数组合起来。
module.exports = {
output: {
filename: 'js/[name].[contenthash:8].js',
chunkFilename: 'js/[name].[contenthash:8].chunk.js',
hashFunction: 'xxhash64',
hashDigest: 'hex',
hashDigestLength: 8,
hashSalt: 'my-project-salt',
},
optimization: {
realContentHash: true,
},
};
这里需要特别说明 realContentHash: true。Webpack 5 中，如果使用 contenthash 且存在异步 chunk，Webpack 在首次计算哈希时可能会使用入口 chunk 的内容来估算，导致异步 chunk 的哈希值不够精确。开启 realContentHash 后，Webpack 会进行额外的一轮哈希计算，确保异步 chunk 的文件名直接反映其真实内容，进一步减少缓存误判。
哈希长度的选择是一个权衡过程。虽然更短的哈希能节省 URL 长度，但太短会增加碰撞概率。实际项目中建议至少保留 8 位，如果资源数量庞大，可以使用 12 位或 16 位。Precision 精确度并不是要求无限压缩，而是让开发者有能力根据自身规模做出精确选择，避免默认值带来的不确定性。
精确代码分割与 Tree Shaking 的协同
代码分割的颗粒度直接影响页面加载性能和缓存复用率。Webpack 5 的 splitChunks 配置提供了多个阈值参数，让开发者可以精确控制 chunk 的大小和数量。例如 minSize 指定模块达到多大体积才会被单独分割，maxSize 则强制 chunk 超过该大小时尝试继续拆分。这些阈值不再是粗略的建议，而是精确的控制点。
在 cacheGroups 中，enforceSizeThreshold 可以强制某个缓存组必须达到指定大小才生效，避免零散的小模块被单独拆成过多异步请求。通过合理设置这些参数，构建产物中的 chunk 数量会保持稳定，不会因为新增几个小模块就产生新的文件，从而让缓存策略更容易维护。下面的配置是一个典型实践。
module.exports = {
optimization: {
splitChunks: {
chunks: 'all',
minSize: 20000,
maxSize: 50000,
maxInitialRequests: 4,
cacheGroups: {
vendors: {
test: /[\/]node_modules[\/]/,
name: 'vendors',
priority: -10,
enforceSizeThreshold: 30000,
},
},
},
},
};
Tree Shaking 的精度同样影响最终产物。Webpack 5 中 optimization.usedExports 默认开启，它会在编译阶段标记哪些导出被使用，配合 sideEffects 配置可以更精确地删除未引用的代码。对于组件库或工具库，建议在 package.json 中显式声明 sideEffects: false，让 Webpack 可以安全地移除无副作用模块。
此外，optimization.concatenateModules 会将多个模块合并到一个作用域中，减少运行时代码和函数调用开销。这种合并需要在精确分析模块依赖关系的基础上进行，Webpack 5 的依赖分析比 4 更加准确，因此合并后的产物往往更小且执行更快。配置这些选项后，构建结果不再受模块顺序和引入方式的影响，体积波动明显降低。
实战：用 Precision 配置提升 CDN 缓存命中率
假设一个单页应用使用 CDN 分发静态资源，并配置了强缓存策略。升级 Webpack 5 后，如果没有设置 moduleIds 和 chunkIds 为 deterministic，每次发布新版本时，即使业务代码没有改动，所有异步 chunk 的文件名也可能发生变化。这会导致用户重新下载全部资源，CDN 命中率大幅下降。引入 Precision 精确度配置后，只有实际变化的 chunk 会生成新的文件名，其余资源继续命中缓存。
在实际项目中，建议将上述所有配置整合到一个 webpack.config.js 中，同时配合 output.clean 清理旧文件。通过对比构建日志中的文件名列表，可以直观看到哪些 chunk 保持不变，哪些 chunk 因内容变更而生成了新哈希。这种可观察性正是 Precision 精确度带来的额外价值。
需要注意的是，精确度配置并非一次性设置后就可以高枕无忧。当项目规模增长或依赖关系发生变化时，需要重新评估 splitChunks 阈值和哈希长度。例如如果某个公共模块的体积超过了 maxSize，Webpack 会尝试拆分它，但拆分结果可能产生更多小 chunk，此时应调整 maxSize 或 minSize 来平衡请求数量与缓存粒度。只有持续关注构建产物的变化趋势，才能让 Precision 精确度持续发挥价值。
总之，Webpack 5 的 Precision 精确度并不是一个独立的新功能开关，而是通过模块标识、哈希输出和代码分割等多层配置协同实现的一套构建控制理念。理解并掌握这些参数，可以让构建产物更稳定、缓存更高效，减少线上发布时的意外变数。