核心是让内容变化的资源拥有新url，浏览器自然不复用旧缓存——文件指纹哈希值正是实现这一点最直接、最可靠的方式；webpack中应使用[contenthash]确保内容变则url变、内容不变则缓存复用，配合html自动注入、静态资源哈希命名及服务端长/短缓存策略协同生效。
核心是让内容变化的资源拥有新 URL，浏览器自然不复用旧缓存——文件指纹哈希值正是实现这一点最直接、最可靠的方式。
为什么哈希值能解决缓存失效
浏览器缓存依赖 URL 作为唯一标识。默认打包如 app.js 名字不变，内容变了，浏览器仍读本地旧文件。而加入内容哈希后，例如变成 app.a1b2c3.js，URL 已完全不同，浏览器判定为全新资源，必须重新请求下载。
关键在于：哈希必须基于文件内容生成（如 Webpack 的 [contenthash]），这样内容一变，哈希就变；内容不变，哈希也不变，缓存可继续复用。
Webpack 中正确配置文件指纹
避免使用全局 [hash]（整个构建变动就全失效），推荐按资源类型区分：
-
JS/CSS 文件：用
[contenthash]，确保仅内容变更才更新文件名 - HTML 模板：不加哈希，但需自动注入带哈希的 JS/CSS 引用（如 HtmlWebpackPlugin）
-
图片/字体等静态资源：同样用
[contenthash]或[name].[contenthash:8].[ext]控制长度
示例（vue.config.js 或 webpack.config.js）：
output: {filename: 'js/[name].[contenthash:8].js',
chunkFilename: 'js/[name].[contenthash:8].js'
}
Nginx 配合强缓存策略
文件带哈希后，就可以放心设置长期缓存，无需担心更新不生效：
- 对
/assets/或/js/等含哈希路径的资源，设Cache-Control: public, max-age=31536000, immutable - 对根目录下的
index.html，设Cache-Control: no-cache或max-age=0，强制每次验证 - 确保 HTML 本身不被 CDN 或 Nginx 缓存太久，否则用户可能加载到旧 HTML，引用的仍是旧哈希文件
额外注意点
光有哈希还不够，几个易忽略细节决定成败：
- 检查构建产物中所有资源是否真带哈希——尤其第三方库 chunk、动态 import 生成的文件
- 确认 HTML 中 script/link 标签的 src/href 是构建后自动替换的，不是手写死的
app.js - CDN 或反向代理（如 Nginx proxy_cache）若缓存了 HTML，需配合 purge 或版本路径刷新，否则哈希再准也白搭
- 开发时禁用缓存调试（Chrome DevTools → Network → Disable cache），避免误判
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
