现代浏览器完全忽略，因其缓存决策由服务器响应头决定，且发生在html解析前；devtools中看到的cache-control值100%来自服务器，与meta无关。
现代浏览器（Chrome、Firefox、Safari、Edge）完全不执行 meta http-equiv="Cache-Control" 的缓存控制指令——它对实际缓存行为零影响，写了也白写。
为什么 DevTools 里看不到 meta 生效的 Cache-Control？
因为浏览器压根不解析这行 meta。HTTP 缓存决策在请求响应阶段就已完成，而 meta 是 HTML 解析阶段才读取的内容，此时缓存策略早已锁定。
- 你在 Network 面板看到的
Cache-Control值，100% 来自服务器响应头，和<meta>无关 - 即使把
<meta http-equiv="Cache-Control" content="no-cache">放在最开头，也改变不了结果 - 用
file://协议打开页面时，连 HTTP 头都没有，meta更是彻底失效——但这常被误当作“它本来能工作”
哪些 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），但行为不统一，生产环境应优先走响应头 -
Cache-Control、Expires、Pragma：Chrome 90+、Firefox 80+、Safari 15+ 已全部移除解析逻辑
测试 meta 缓存指令是否生效的唯一可靠方式
别信刷新、别信 F5、别信“我改了 HTML 所以肯定生效了”。真验证只有一条路：
- 确保页面通过
http://或https://访问（file://下无效） - 打开 DevTools → Network → 刷新页面 → 找到 HTML 请求 → 点开 Headers 标签页
- 只看
Response Headers区域里的Cache-Control字段 —— 它的值必须来自服务器，而不是你写的meta - 如果 Status 显示
200 from disk cache或304 Not Modified，说明缓存行为由服务端头决定，和meta无关
真正容易被忽略的是：开发者常花时间调试 meta 写得对不对，却没检查 Nginx 或 CDN 是否给 HTML 返回了 Cache-Control: public, max-age=3600 —— 那才是问题源头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
