核心方案是分而治之：静态资源（js/css等）启用含immutable的一年强缓存，HTML文件（/和.html）禁用缓存（no-cache或no-store），SPA回退规则须置于静态规则之后，并通过Network面板验证响应头。
核心思路是“分而治之”：让带 hash 的静态资源走强缓存，让不带 hash 的 HTML 文件禁用缓存。这样既保证用户能快速加载 JS/CSS，又确保每次访问都能拿到最新版入口文件，自然绕开旧 hash 资源被缓存的问题。
一、静态资源启用强缓存（关键在 immutable）
Webpack/Vite 打包生成的 js/css/img 等文件名含内容 hash（如 app.a1b2c3.js），说明内容变了文件名就变，因此可放心长期缓存：
- 在
location块中匹配常见静态后缀，设置一年有效期 +immutable -
immutable是关键：告诉浏览器“这个 URL 永远不会变”，即使用户手动刷新也不会重新验证，大幅提升加载速度 - 配置示例：
expires 1y;
add_header Cache-Control "public, immutable";
}
二、HTML 文件必须禁用缓存
index.html 是所有资源的“总入口”，它本身不带 hash，但内部引用的 JS/CSS 路径会随每次构建更新。如果 HTML 被浏览器缓存，用户就可能加载到旧 HTML → 引用旧 hash 资源 → 404 或白屏。
- 对根路径
/和所有.html文件显式关闭缓存 - 使用
no-cache（强制校验）或更严格的no-store（完全不缓存） - 配置示例：
try_files /index.html =404;
add_header Cache-Control "no-cache, must-revalidate";
}
location ~* \.html$ {
add_header Cache-Control "no-store";
}
三、SPA 回退要避开静态规则干扰
单页应用（Vue/React）依赖前端路由，用户直接访问 /user 时，Nginx 需 fallback 到 /index.html。但这个 location / 规则不能放在静态资源规则之前，否则 js/css 请求会被错误地 fallback，跳过强缓存。
立即学习“前端免费学习笔记（深入）”；
- 把静态资源
location ~*放在前面，通用回退location /放在后面 - 确保
try_files $uri $uri/ /index.html只兜底非静态请求 - 多项目部署时，注意前缀匹配优先级（如
location ^~ /h5/应早于location /）
四、上线后快速验证是否生效
别只信配置，要用浏览器 Network 面板实测：
- 刷新页面，查看
index.html的响应头：Cache-Control 应为no-cache或no-store - 查看一个 JS 文件（如
app.xxx.js）：Cache-Control 应含immutable，Expires 应为 1 年后 - 手动改一行 HTML 内容、重新打包部署后，清空浏览器缓存再访问——若仍看到旧页面，说明 HTML 缓存没禁掉，重点检查 Nginx 配置是否被其他
include覆盖
