哈希指纹通过文件名变化强制浏览器拉取新资源，核心是用contenthash使URL随内容变更；Webpack需配置JS/CSS/图片使用[contenthash]，HtmlWebpackPlugin自动注入带哈希的链接；Nginx对哈希资源设长期缓存且immutable，HTML设no-cache；上线后验证文件名、响应头及缓存状态。
靠文件名变化触发浏览器重新拉取，而不是等旧缓存过期——这是哈希指纹解决缓存失效最本质的逻辑。构建时把内容哈希塞进文件名，内容一变，URL 就变，浏览器自然当它是新资源。
用 contenthash 替代 hash
Webpack 默认的 [hash] 是整个构建的摘要，哪怕只改一行 CSS，所有 JS 文件哈希全变，导致大量缓存浪费。真正该用的是 [contenthash]，它只跟单个文件内容绑定：
- JS 文件：output.filename 设为
js/[name].[contenthash:8].js - CSS 文件：mini-css-extract-plugin 的 filename 同样用
[name].[contenthash:8].css - 图片/字体：assetModuleFilename 配置成
assets/[name].[contenthash:8].[ext]
HTML 自动注入带哈希的资源链接
光改 JS/CSS 名字没用，HTML 还得引用新地址。靠 HtmlWebpackPlugin 实现自动注入：
- 它读取 webpack 打包后的真实文件名（含哈希），写进生成的 index.html
- 确保 template 中不硬编码
app.js，而是留空或用占位符，由插件填充 - Vite 默认就做这事，无需额外配置；Vue CLI 或自建 Webpack 项目需确认插件已启用
Nginx 配合长缓存 + HTML 协商缓存
文件带哈希后，就可以大胆设长期缓存，但 HTML 必须反着来：
立即学习“Java免费学习笔记（深入）”；
- 对
/js/、/css/、/assets/下含哈希的路径，加响应头：Cache-Control: public, max-age=31536000, immutable - 对根目录下的
index.html，设为：Cache-Control: no-cache或max-age=0，强制每次向服务器验证 - 避免 CDN 或 Nginx 把 HTML 缓存太久，否则用户看到的还是旧 HTML，里面引的仍是过期哈希文件
验证是否生效
上线后快速检查三件事：
- 打开开发者工具 → Network，看 JS/CSS 文件名是否含 8 位左右哈希字符串
- 点开某个 JS 文件响应头，确认有
Cache-Control: ... immutable - 刷新页面，观察相同哈希名的资源是否返回 200（from memory cache 或 from disk cache），而非 304
