no-store在<meta>标签中完全失效，因Chrome、Firefox、Edge自2016年起已明确忽略HTML文件的http-equiv="Cache-Control"指令，index.html尤其无效；真正有效的是服务端通过location = /index.html精确匹配并返回Cache-Control: no-store等响应头。
no-store 在 <meta http-equiv="Cache-Control"> 里根本不起作用——现代浏览器（Chrome、Firefox、Edge 自 2016 年起）完全忽略它对 HTML 文件的缓存指令，index.html 尤其无效。
为什么 <meta> 标签里的 no-store 失效
浏览器 Network 面板看到的 200 (from memory cache) 状态，背后响应头里根本没有 Cache-Control 字段；那只是 DOM 被复用的假象，实际没发新请求。W3C 规范允许浏览器对 HTML 主文档绕过 <meta> 指令，尤其在后退/前进、硬刷新等场景下，no-store 彻底被无视。
常见错误现象：
- 改完 JS 逻辑重新发布，用户刷新还是旧版本
- Vue/React SPA 首屏白屏，控制台报 404 或资源加载错乱
- DevTools 里点开
index.html请求，Response Headers 里压根没Cache-Control
Nginx 中 location = /index.html 必须精确匹配
服务端才是唯一可靠的防线。Nginx 配置必须用 location = /index.html，不能写成 location ~* \.html$ 或 location /：
立即学习“前端免费学习笔记（深入）”；
-
location ~* \.html$会把/about.html、/404.html全部强制不缓存，拖慢所有页面首屏 -
location /会让所有静态资源（JS/CSS/图片）也带上no-store，彻底废掉缓存策略 - 必须显式加
Pragma和Expires：老 IE、企业网关、部分 CDN 仍依赖它们，漏掉就可能被中间层覆盖
正确配置片段：
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;
}测试是否真生效，别信 DevTools 的“from memory cache”
状态码必须是 200，不是 304；Size 列显示 from memory cache 是干扰项，直接忽略。
- 用
curl -I https://yoursite.com/index.html查响应头，确认三类头全在 - Chrome DevTools → Network → 点开
index.html请求 → Headers → Response Headers，逐行核对 - 测试务必用
Ctrl+Shift+R硬刷新，或新开无痕窗口；普通 F5 极大概率走内存缓存 - CDN（如 Cloudflare）或反向代理常悄悄覆盖
add_header，得实测线上地址，不能只看本地 Nginx 日志
meta 标签只在极端兜底时用，且仅限开发阶段
只有当你完全无法改服务端配置（比如 GitHub Pages、Vercel 静态托管且禁用函数），才考虑在 <head> 里补一句：
<meta http-equiv="Cache-Control" content="no-store">
但它只对 HTML 文件本身有极弱作用，不影响 JS/CSS 缓存，也不能防止白屏。上线前必须切回服务端方案。
容易被忽略的一点：expires 1h 这类全局指令会覆盖 add_header，检查 Nginx server 块顶部是否误写了它。
