Webpack中[contenthash]为何不一致？生成文件名与实际哈希不符

先还原你的场景 #

你在webpack配置里指定用[contenthash:32]生成chunk文件名：

module.exports = {
    entry: { app: './src/main.js', },
    output: {
        path: path.resolve(__dirname, './dist/js/'),
        publicPath: '/js/',
        filename: '[name].js',
        chunkFilename: 'chunk/[contenthash:32].js', // use contenthash here
        hashDigestLength:32,
    }
}

但实际生成的文件名哈希是28024a27808de6fae79a1f5596584d3e，手动计算文件内容的哈希却是9c757e82e0a41d8e51228532a109a0d7，两者不匹配，这其实是webpack设计机制导致的，主要有这几个原因：

• Webpack的contenthash不是直接对最终输出文件做哈希
  别被名字误导了，contenthash并不是拿最终输出的JS文件直接做哈希计算。它的计算依据是chunk编译过程中内部模块的摘要信息——包括模块的源代码内容、模块依赖关系、webpack注入的模块加载逻辑元数据等，是webpack在编译阶段对chunk的“逻辑内容”生成的哈希，而非最终落地到磁盘的文件内容。

• 代码优化插件会修改最终文件内容（最常见原因）
  如果你配置了代码压缩（比如TerserPlugin）、混淆、移除注释或者其他代码优化插件，webpack的执行顺序是：

  1. 先编译模块生成未优化的chunk内容
  2. 基于这个未优化的内容计算contenthash，确定文件名
  3. 再对chunk内容做压缩、混淆等优化处理，生成最终的文件
     这时候最终文件的内容已经和计算contenthash时的原始内容不一样了，手动计算的哈希自然和文件名里的contenthash不匹配。

• 可能包含了webpack runtime的变动
  如果你的chunk中包含了webpack自动注入的runtime代码（比如模块加载器、chunk依赖管理逻辑），这部分代码的细微变动（哪怕只是变量名、模块ID的变化）都会影响contenthash，但你手动计算文件哈希时可能没意识到这部分是webpack自动添加的，或者误以为它不会影响哈希结果。

简单来说，contenthash是webpack用来标识chunk编译逻辑唯一性的哈希，而不是最终文件内容的哈希，两者的计算对象本身就不一样，出现差异是正常的。

内容的提问来源于stack exchange，提问作者Wayne