现代浏览器完全忽略，尤其对index.html无效；真正有效的是服务端精确配置location = /index.html并返回cache-control: no-store等响应头。
现代浏览器根本不理 <meta http-equiv="Cache-Control">
别再往 里塞 <meta http-equiv="Cache-Control" content="no-store"> 了。Chrome、Firefox、Edge 自 2016 年起就明确忽略它对 HTML 的缓存指令，index.html 尤其完全无效。DevTools Network 面板里你看到的 200 (from memory cache) 状态，背后响应头里压根没有 Cache-Control 字段——那只是浏览器在用已加载的 DOM 假装刷新，实际没发新请求。
唯一能起效的，是服务端返回的真实 HTTP 响应头。哪怕你托管在 GitHub Pages 或 Vercel 静态模式，也只在「完全无法改服务端配置」时，才把 <meta> 当临时补救手段用，且仅对 HTML 文件本身有限作用，不影响 JS/CSS。
Nginx 必须用 location = /index.html 精确匹配
写成 location ~* \.html$ 或 location / 都不行：前者会误伤所有 HTML（比如 /about.html 也被强制不缓存，拖慢首屏）；后者会让所有资源（图片、JS）都带上 no-store，彻底废掉静态资源缓存策略。
正确做法是单独锁定主入口：
location = /index.html {
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate";
add_header Pragma "no-cache";
add_header Expires "0";
add_header Last-Modified $date_gmt;
}
-
no-store是底线：禁止任何副本留存，no-cache还可能触发 304 协商，SPA 场景下极易白屏 -
Pragma和Expires必须显式加，不是可选——老 IE 和部分代理仍依赖它们 -
Last-Modified要设，否则某些 CDN 会拒绝透传你设的头
CDN 和反向代理常悄悄覆盖你的响应头
Cloudflare、Nginx proxy_pass、甚至某些企业网关，默认会删掉或重写 add_header 设置的字段。验证时不能只看本地 Nginx 日志，得真跑一次请求：
- 用
curl -I https://yoursite.com/index.html，检查输出里有没有Cache-Control: no-store - Chrome DevTools → Network → 点开
index.html请求 → Headers → Response Headers，确认三类头全在 - 状态码必须是
200，不是304；Size 列显示from memory cache是假象，直接忽略 - 测试务必用
Ctrl+Shift+R硬刷新，或新开无痕窗口——普通 F5 可能走内存缓存
HTML 不缓存 ≠ 其他资源也不缓存
只禁 HTML 缓存，是为了确保每次加载都是最新版本的入口文件；但 JS/CSS/图片必须长期缓存，否则首屏性能崩盘。Nginx 配置要分层：
-
location = /index.html：上文的no-store严格策略 -
location ~* \.(js|css|png|jpg|woff2)$：加Cache-Control public, max-age=31536000, immutable - 千万别在全局
location /里统一加no-store，那是自毁式配置
另外，SPA 内部路由跳转后数据没更新？大概率是 fetch 默认走 HTTP 缓存，得在请求里显式写 cache: "no-store"，光靠 HTML 不缓存解决不了这个问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
