webpack长缓存优化核心是contenthash：js/css/图片用contenthash生成文件名确保内容变则url变，html通过htmlwebpackplugin自动注入新链接，nginx对哈希资源设immutable长期缓存、对index.html设no-cache。
Webpack 实现长缓存优化，核心是让静态资源（JS、CSS、图片等）具备“内容决定 URL”的能力——即文件内容不变，URL 就不变；内容一变，URL 必然变。浏览器靠 URL 缓存资源，URL 变了，就自然拉新资源，旧缓存彻底失效。这背后的关键技术就是文件指纹，而实现它最稳妥的方式是用 contenthash。
用 contenthash 生成稳定、精准的文件名
Webpack 提供了多种哈希方式，但只有 [contenthash] 是真正按文件内容生成的：
- JS 文件：配置
output.filename: 'js/[name].[contenthash:8].js'，每个 JS 文件独立计算哈希，改一个文件，只影响它自己 - CSS 文件：配合
MiniCssExtractPlugin，设置filename: 'css/[name].[contenthash:8].css' - 图片/字体等静态资源：在
assetModuleFilename中使用assets/[name].[contenthash:6].[ext]，控制长度也兼顾可读性 - 避免使用
[hash]（全构建级）或[chunkhash]（入口级），它们无法保证 CSS 与 JS 解耦更新，容易导致缓存错乱
HTML 自动注入带哈希的资源链接
光改 JS/CSS 名字没用，HTML 还得引用新地址。否则用户加载的仍是旧 HTML，里面写的还是 app.js，缓存问题照旧：
- 用
HtmlWebpackPlugin，它会读取 Webpack 输出的真实文件名（含哈希），自动写入<script></script>和<link>标签 - HTML 模板中不要硬编码资源路径，留空或用占位符，交由插件填充
- Vite 或 Vue CLI 默认已集成该能力，自建 Webpack 项目需确认插件已启用且配置正确
Nginx 配合强缓存策略，各司其职
文件带哈希后，就可以放心对静态资源设长期缓存，但 HTML 必须反着来：
- 对含哈希路径的资源（如
/js/app.a1b2c3.js），响应头设为：
Cache-Control: public, max-age=31536000, immutable - 对根目录下的
index.html，必须设为短缓存或不缓存：
Cache-Control: no-cache 或 max-age=0 - 特别注意：CDN 或 Nginx 若把 HTML 缓存太久，用户就会一直加载旧 HTML，里面引用的仍是过期哈希资源——这是上线后最常见的缓存失效原因
上线后快速验证是否生效
发布后打开开发者工具 Network 面板，三件事马上能确认：
- 看 JS/CSS 文件名是否含 8 位左右哈希字符串（如
main.7f3a1e2d.js） - 点开某个 JS 文件，检查响应头是否有 Cache-Control: immutable
- 刷新页面，相同哈希名的资源应返回 200 (from memory cache)，而非 304
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
