对静态资源进行hash命名，可以选择哪些方式？

在 项目打包 过程中，我们通常会对输出的静态资源（如 JS 、CSS 文件）进行 带哈希值的命名 。其核心目的是实现 高效的浏览器缓存 策略：

1. 当文件内容未发生变化时，文件名保持不变，浏览器可直接使用本地缓存，避免重复下载；
2. 当文件内容发生变更时，文件名随之更新，确保用户能及时加载最新版本的资源。
   Webpack 等构建工具提供了多种哈希命名方式，常见的有 hash 和 contenthash。·

hash 基于整个构建过程生成，任意文件变动都会导致所有资源哈希值变化；

output: {
    filename: 'js/[name].[hash].js',
    chunkFilename: 'js/[name].[chunkhash].js',
},
miniCssExtractPluginOption: {
    filename: 'css/[name].[hash].css',
    chunkFilename: 'css/[name].[chunkhash].css',
},

contenthash 则根据文件自身内容计算，仅当该文件内容改变时，其哈希值才会更新。

output: {
   filename: 'js/[name].[contenthash:8].js', 
   // 使用contenthash代替hash，有利于缓存
   chunkFilename: 'js/[name].[contenthash:8].chunk.js',
},
miniCssExtractPluginOption: {
   filename: 'css/[name].[contenthash:8].css',
   chunkFilename: 'css/[name].[contenthash:8].chunk.css',
},

因此，推荐在生产环境中使用 contenthash，以实现更精准的缓存控制，最大化利用缓存并减少不必要的网络请求。

一、hash命名

整个项目任意文件变动（包括JS 、CSS 、图片等），所有资源的 hash 全部发生变化，导致所有缓存失效，用户需要重新下载全部资源

🤔️ 为什么 hash 会导致 "所有缓存失效" ？
webpack 中 filename 的 hash 并不是每个文件自己内容的 hash ，而是基于本次整个构建过程生成的唯一哈希值（只要项目里任意文件变了，hash 就变）

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

二、chunkhash命名

.chunk 后缀可以用来明确区分入口文件（entry）和异步分包（chunk），若该 chunk 及其依赖变化（JS模块树变化），则相关 chunk 失效。

filename 是入口文件（entry chunks）的命名，通常是主应用 JS 文件（如：app.js、index.js）

chunkFilename 是代码分割动态生成的 chunk，常见场景有：

• 动态导入：import('./module')
• 懒加载路由：() => import('./Page')
• webpack 的 SplitChunksPlugin 自动生成的公共 chunk

三、contenthash命名

仅当文件内容本身变化时，文件哈希才会改变。使用 :8 截取前 8 位足够避免冲突（碰撞概率极低），文件名更短，可以减少HTTP请求头体积。若对安全性要求极高（比如：金融级），可增加到10～16位

举例对比：当用户修改了一个 .css 文件

• 使用 hash：所有 JS/CSS 文件名都会变化，用户需要重新下载全部资源；
• 使用 contenthash：只有修改的 css 文件名变化，js 文件名不变

contenthash是目前 Webpack 推荐用于静态资源长期缓存的最佳实践。