现代浏览器（Chrome 90+、Firefox 80+、Safari 15+）完全不解析<meta http-equiv="Cache-Control">，缓存决策在HTTP响应阶段即已完成，DevTools中看到的Cache-Control值100%来自服务器响应头，与meta无关。
Chrome/Firefox/Safari对的实际解析行为
现代浏览器（Chrome 90+、Firefox 80+、Safari 15+）在HTTP请求响应阶段就已完成缓存决策，meta http-equiv="Cache-Control"压根不被解析——不是“没生效”，而是连读都不读。你在DevTools Network面板里看到的Cache-Control值，100%来自服务器响应头，和<meta>标签内容无关。
常见错误现象：改了<meta http-equiv="Cache-Control" content="no-store">后刷新页面，状态码仍是200 from memory cache或304 Not Modified。这不是你写错了，是浏览器根本没把它当指令。
实操验证方式只有一条路径：
- 确保页面通过
http://或https://访问（file://下无HTTP头，属于无效测试场景） - 打开DevTools → Network → 刷新 → 找到HTML请求 → 点开Headers → 只看
Response Headers区域 - 如果
Cache-Control字段存在，它的值一定来自Nginx/Apache/CDN配置，不是<meta>
为什么DevTools里能看到“Cache-Control”却不是meta写的
因为Response Headers显示的是真实HTTP响应头，而<meta http-equiv>模拟的是“本该由服务端发出来的头”。浏览器在收到响应后才开始解析HTML，此时缓存策略早已锁定——<meta>连入场券都没拿到。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的关键点：
-
Cache-Control、Expires、Pragma这三类http-equiv值，已被W3C移出推荐实现范围，主流浏览器明确移除了对应解析逻辑 - 即使把
<meta>放在<head>最开头，也改变不了它被跳过的事实 - 某些老旧WebView（如Electron低版本）可能还残留解析，但这不属于可交付的生产环境保障
哪些http-equiv值现在还能起作用
不是所有http-equiv都被废弃，但能用的和缓存无关：
-
Content-Type：仅用于声明字符集，如content="text/html; charset=utf-8"；错写成encoding会导致乱码 -
Refresh：仍被支持，如content="3;url=/done"可触发跳转，但语义弱、SEO不友好，建议优先用location.replace() -
Content-Security-Policy：Firefox等部分浏览器支持，但行为不统一，生产环境必须走响应头
注意：X-UA-Compatible仅IE有效，Cache-Control类指令在任何现代浏览器中都不再触发缓存行为变更。
服务端不可控时前端唯一可行的绕过手段
托管在GitHub Pages、Netlify、Vercel等静态平台时，<meta>依然无效。真正能落地的方案只有URL扰动和资源哈希：
- 跳转时加时间戳：
window.location.href = "page.html?t=" + Date.now()，比Math.random()更可靠（避免单页内重复） - 关键JS/CSS文件名带内容哈希（如
main.a1b2c3.js），由构建工具自动完成 - HTML自身仍需服务端设
Cache-Control: no-cache，否则新HTML引用旧哈希资源会导致白屏——前端无法替代这一环
真正容易被忽略的是：开发者花时间调<meta>写法是否规范，却没查Nginx里location = /index.html有没有配add_header Cache-Control "no-store"——那才是问题源头。
