Webpack 4：hash 和 contenthash 和 chunkhash，什么时候用哪个？答案

【问题标题】：Webpack 4: hash and contenthash and chunkhash, when to use which?Webpack 4：hash 和 contenthash 和 chunkhash，什么时候用哪个？
【发布时间】：2019-12-05 11:41:28
【问题描述】：

有人向这个建议了similar question，但它只解释了这些哈希之间的区别。

但是，我还是不知道什么时候应该选择[hash] 而不是[contenthash]？谁能给我举个例子吗？

=== 上一个正文 ===

webpack 文档解释了不同的哈希类型如下：

https://webpack.js.org/configuration/output/#outputfilename

哈希：

为每个构建生成唯一的哈希

内容哈希：

为提取的内容生成哈希

chunkhash：

基于每个块内容的哈希：

我仍然对何时使用哪种类型的哈希感到困惑。

[hash] 是为每个构建生成的，但是在使用以下配置多次运行 webpack build 后，我没有发现我的哈希值发生了变化。

module.exports = {
  output: {
    filename: '[name].[hash].js'
  }
}

Webpack 版本 4.41.2

我还发现react-scripts里面的webpack config是用contenthash来处理js和css文件，而用hash来处理像图片这样的assets文件，这也让人困惑，他们为什么要这样，[hash]更好二进制文件的选项？

【问题讨论】：

这能回答你的问题吗？ What is the purpose of webpack [hash] and [chunkhash]?
@Sunil 我现在知道 hash 和 contenthash 的区别了，但是什么时候应该使用 hash 而不是 contenthash？如果“使用 contenthash 更好”，是不是意味着我可以完全忘记 hash，只使用 contenthash ？

标签： webpack

【解决方案1】：

假设您生成了三个捆绑包：

main.js
main.css
vendor.js

main.js 文件中引用的 main.css。

哈希：

将为每个构建生成哈希数。生成的哈希数所有捆绑的文件都将相同。

例如：

Hash: 66e665r76798c278ytr6

Generated Files:
main.66e665r76798c278ytr6.js
main.66e665r76798c278ytr6.css
vendor.66e665r76798c278ytr6.js

所有三个文件都将包含相同的哈希数。这个哈希值是一样的只要您没有更改文件的任何内容。即使您运行许多构建在不改变任何内容的情况下，哈希数将相同。

ChunkHash：

在这种情况下，将根据入口点生成哈希数并且所有文件都会有所不同。

Hash: 66e665r76798c278ytr6

Generated Files:
main.77e665r76798c278ytr6.js
main.78e665r76798c278ytr6.css
vendor.79e665r76798c278ytr6.js

如果您没有更改供应商文件，则生成的供应商文件的哈希值将相同。但是如果你添加任何新的供应商，hash number 将会改变。

如果您在 main.js 中进行了任何更改，main.js 和 main.css 将有新的哈希数字，因为哈希数字是根据入口点改变的。

内容哈希：

仅当您对特定的内容进行任何更改时才会生成哈希文件，每个文件都有唯一的编号。

例如，如果您只更改了 main.js 文件，则只会生成新的哈希对于更改的文件，其他两个哈希将与以前的构建相同

Chunkhash 和 ContentHash 都会为每个生成的文件生成哈希值。唯一的区别是 ChunkHash 基于入口点生成哈希。

在大多数情况下，您将使用 ContentHash 进行生产。

借助 contenthash，您可以在浏览器中实现长期缓存。只要哈希值保持不变，浏览器就会提供缓存文件。

https://github.com/webpack/webpack.js.org/issues/2096

长期缓存： 为了提高应用加载时间，我们经常使用缓存。在应用程序的初始加载期间，我们可以设置标题对于作为 Cache-Control 的资产：max-age=31536000。之后，浏览器将缓存资产和后续请求将从缓存中获得。

没有散列：

假设您对某些资产（例如 main.js）进行了更改，因为您已将 max-age 指定为 31536000，因此新的更改将没有得到反映，浏览器将继续从缓存中提供服务。

使用散列：

为了覆盖它，我们在所有文件中使用哈希。如果您对文件进行了任何更改，新的哈希将是生成，浏览器将其视为新请求。

示例：

您仅在 main.js 中进行了更改。在 [hash] 的情况下，所有文件都将获得新的哈希数。浏览器将所有三个都视为新请求并发出三个新请求以获取文件

[contenthash] 不是这种情况。如果你提到了 contenthash，那么只有 main.js 的 hash 会被改变。其他两个文件将具有相同的哈希值，并将继续从浏览器缓存中提供服务。

这将缩短您的应用加载时间。

如果您需要实现长期缓存，则建议使用 contenthash 而不是普通的哈希。

生成哈希会增加应用编译时间。所以你会在生产过程中使用 contenthash/hash。

【讨论】：

很好的解释，但@Littlee 提出的主要问题BUT, I still can't figure out when should I choose [hash] instead of [contenthash]? Can someone show me an example situation? 的答案仍然缺失。请同时添加。
这个答案很有帮助，所以总结一下，hash 可以通过覆盖实现长期缓存，而 contenthash 在大多数情况下是更好的选择。（如果我只修改我的几个文件，我认为我不会更改所有文件的哈希值，哈哈）
在 webpack 5 中，“hash”已被弃用，现在您只能选择使用“contenthash”
应更新此答案以反映 WebPack 5+ 中的更改。它现在只支持 contenthash，所以答案要容易得多。