前端构建工具生成带哈希文件名实现缓存失效，nginx需用正则匹配哈希资源（如. [a-f0-9]{8,32}.(js|css|png|...)$），配cache-control "public, max-age=31536000, immutable"；html必须禁长期缓存，设no-cache或no-store。
前端构建工具（如 Webpack、Vite、Rollup）在打包时自动生成带内容哈希的文件名（例如 main.a1b2c3d4.js、style.e5f6g7h8.css），本质是让文件内容变化 → 文件名变化 → URL 变化 → 浏览器自然失效旧缓存。Nginx 需要识别这类文件，并施加激进但安全的缓存策略，才能真正发挥指纹价值。
匹配带哈希的静态资源路径
Nginx 不能靠后缀判断是否可长期缓存，而应通过正则精准识别含哈希片段的文件名。常见哈希长度为 8–32 位十六进制字符，推荐使用如下 location 块：
-
匹配模式示例：
location ~* \.[a-f0-9]{8,32}\.(js|css|png|jpg|jpeg|gif|svg|webp|woff2?|ttf|eot)$ - 该规则避开普通
app.js或logo.png，只命中带哈希的产物，避免误伤未哈希资源 - 若构建工具用短哈希（如 6 位），可调为
{6,32}；若用时间戳或版本号（如.v2.3.1.js），需相应调整正则
配置强缓存头：max-age + immutable
对匹配到的哈希文件，必须启用「强制缓存终极形态」——immutable，它让浏览器连刷新都不发验证请求：
add_header Cache-Control "public, max-age=31536000, immutable" always;-
always参数确保即使 upstream 返回 4xx/5xx，头也照样生效（防止错误响应破坏缓存逻辑） - 不建议混用
expires 1y和Cache-Control，因两者冲突时浏览器以Cache-Control为准；专注用后者更可控
严格隔离 HTML 缓存策略
HTML 是唯一不带哈希的入口文件，必须禁止长期缓存，否则用户可能加载旧 HTML，引用已失效的新哈希资源：
location = / { try_files /index.html =404; add_header Cache-Control "no-cache, must-revalidate"; }location ~* \.html$ { add_header Cache-Control "no-store"; }- CDN 层也需同步设置
*.html缓存时间为 0 或 1 秒，防止边缘节点缓存 HTML
验证是否生效的关键动作
光配对不行，得确认浏览器真实行为：
- 用 Chrome DevTools 的 Network 面板查看 JS/CSS 请求的响应头，确认含
Cache-Control: public, max-age=31536000, immutable - F5 刷新后，该资源应显示
(from memory cache)或(from disk cache)，且无网络请求发出 - 修改 HTML 中某 JS 引用路径（如把
app.a1b2c3.js改成app.x9y8z7.js），部署后访问，应加载新文件且旧文件缓存不受影响
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
