<meta http-equiv>标签对index.html缓存控制完全无效，现代浏览器自2018年起已彻底忽略它，缓存策略必须由服务端HTTP响应头（如Cache-Control）决定，且需通过location = /index.html精确配置并验证Response Headers生效。
<meta http-equiv> 标签对 index.html 的缓存控制完全无效，现代浏览器（Chrome、Firefox、Safari、Edge）自 2018 年起已彻底忽略它。你写再多 <meta http-equiv="Cache-Control" content="no-store">，Network 面板里都看不到对应响应头，状态码照样是 200 from memory cache —— 缓存照常生效，问题照旧发生。
为什么 <meta http-equiv="Cache-Control"> 不能用
这个标签本意是模拟 HTTP 响应头，但实际执行权不在 HTML，而在服务端返回的响应头。HTTP 规范明确要求：缓存策略以服务端响应头为准，meta 仅作为无响应头时的极弱 fallback，且仅旧版 IE 曾部分支持。2026 年所有主流浏览器收到任意 Cache-Control 响应头后，直接跳过 meta 解析；即使没收到，也不再按它决策缓存行为。
常见误判场景：
- 本地用
file://协议打开 HTML —— 根本没有 HTTP 头，缓存逻辑本就不启动，此时“看似生效”纯属错觉 - DevTools 里看到
index.html请求的 Size 是from disk cache，却以为是meta起了作用 - 上线后用户白屏或加载旧 JS，排查半天才发现
meta从没被读过
Nginx 中精确匹配 /index.html 的配置写法
唯一可靠路径是服务端配置，且必须用 location = /index.html 精确匹配。任何模糊写法都会出问题：
立即学习“前端免费学习笔记（深入）”；
-
location /index.html→ 匹配所有以/index.html开头的路径，比如/index.html?debug=1或/index.html.backup -
location ~* \.html$→ 波及所有 HTML 文件，可能把about.html也套上no-cache，破坏预期
正确配置示例：
location = /index.html {
add_header Cache-Control "no-cache, must-revalidate, max-age=0";
add_header Pragma "no-cache";
add_header Expires "0";
add_header ETag "";
}关键点：
-
no-cache, must-revalidate, max-age=0组合比单用no-store更合理：既避免强缓存导致白屏，又保留内存缓存提升首屏速度 -
ETag ""让 Nginx 自动生成基于内容的校验值，确保协商缓存（304）可触发 - 务必检查 server 块顶部是否误写了全局
expires 1h—— 它会覆盖add_header
验证缓存策略是否真正生效的三步法
别信地址栏回车或 F5，它们可能走内存缓存或强制校验。真实效果只能靠 Network 面板确认：
- 打开 DevTools → Network → 勾选 Disable cache（仅调试用，不影响实际策略）
- 新开无痕窗口 → 访问页面 → 找到
index.html请求 → 点开 Headers 标签页 - 确认 Response Headers 中存在
Cache-Control: no-cache, must-revalidate, max-age=0，且 Status 是304 Not Modified（协商缓存生效）或200 OK（首次加载）
如果 Status 是 200 from disk cache，说明强缓存意外命中 —— 配置没生效，回去查 location = 是否写错、是否有 upstream 覆盖响应头。
最容易被忽略的是：HTML 缓存策略必须和构建产物联动。Webpack/Vite 打包生成带哈希的 JS/CSS，但若 index.html 被 CDN 长期缓存，用户拿到的仍是引用旧哈希的老 HTML —— 所以服务端配置不是“可选项”，而是发布链路里不可绕过的环节。
