现代浏览器基本忽略<meta http-equiv="Cache-Control">，其缓存行为完全由服务器响应头决定，仅在file://协议等非HTTP场景下可能“看似生效”，但不可依赖。
meta http-equiv="Cache-Control" 在现代浏览器里到底有没有用
基本没用，尤其是你刚改完代码、刷新页面发现还是旧版本的时候。Chrome 124+、Firefox 125+、Safari 17+ 都只把 <meta http-equiv="Cache-Control"> 当作弱提示，不参与 HTTP 缓存决策。它既不能覆盖服务端返回的 Cache-Control: public, max-age=3600，也不影响 JS/CSS/图片等资源的缓存行为——那些全由各自响应头控制。
唯一可能“看起来生效”的场景是：本地双击打开 file:// 协议的 HTML 文件（无服务器），或者老旧 WebView 环境。但这和真实线上环境完全脱节，不能作为验证依据。
如果非要用 meta，只保留这一行
别堆砌 no-cache, no-store, must-revalidate, max-age=0 —— 这些指令语义冲突，反而增加解析不确定性。现代浏览器只认 no-store 的语义：禁止任何缓存存储，连内存都不留。
-
<meta http-equiv="Cache-Control" content="no-store">必须放在<head>最早位置，且前面不能有 JS 执行或服务端输出提前触发文档流 - 大小写敏感：
Cache-Control首字母必须大写，cache-control在旧 IE 中可能失效 - 删掉所有其他缓存相关 meta：
<meta http-equiv="Pragma">已被所有主流浏览器忽略；<meta http-equiv="Expires">属于 HTTP/1.0 遗留，W3C 不要求支持
跳转后页面仍被缓存？meta 完全不负责这事
当你用 window.location.href = "page.html" 跳转，目标页是否缓存，只取决于 page.html 自己的 HTTP 响应头，跟源页面的 meta 毫无关系。这也是为什么加了一堆 meta，点「返回」按钮还是看到 stale 页面——那大概率是 bfcache（back/forward cache），和 HTTP 缓存无关，<meta> 根本不参与控制。
立即学习“前端免费学习笔记（深入）”；
前端能做的临时补救只有 URL 扰动：
- 用
Date.now()而不是Math.random()，避免单页内多次调用生成重复值 -
window.location.href = "page.html?t=" + Date.now()—— 强制 URL 唯一，绕过缓存匹配逻辑 - 不要用
location.replace()，它不产生历史记录，但缓存行为和href完全一致
真正该盯住的地方：服务端响应头
禁用缓存的唯一可靠路径是让服务端对每个资源返回明确的 Cache-Control 头。HTML 页面、JS、CSS、API 接口都要单独配置，缺一不可。CDN 或反向代理（如 Cloudflare、Nginx）可能覆盖或删掉你设的头，必须确认透传。
开发阶段快速验证方式：
- Chrome DevTools → Network → 点开请求 → Headers → Response Headers 区域找
Cache-Control字段 - 用
curl -I https://yoursite.com/page.html直接看响应头 - 如果看到
ETag且后续请求带了If-None-Match，说明no-store没生效，服务器仍在走协商缓存
最常被忽略的一点：即使你在 HTML 里写满了 meta，只要服务端返回的是 Cache-Control: public, max-age=3600，浏览器就按这个执行——截至 2026 年 6 月，没有例外。
