http-equiv是html中模拟http响应头的机制，仅对当前html文档生效且须置于head最前；它不发送真实http头，现代浏览器优先采用服务端响应头，部分值（如expires、set-cookie）已废弃或不支持。
http-equiv 不是发 HTTP 头，只是“告诉浏览器这么处理”
它不改变服务器实际返回的响应头，只在浏览器解析 HTML 时起作用——相当于给当前页面打一个“行为补丁”。比如 meta http-equiv="Cache-Control" 写了，但服务器返回了 Cache-Control: public, max-age=3600，那浏览器一定听服务器的，meta 被忽略。
常见误解是以为加了就能强制生效，其实它只在以下条件下有机会起效：
- 必须放在
最开头，越早越好；否则浏览器可能已开始渲染或缓存决策 - 仅对当前 HTML 文档本身有效，不影响后续加载的 JS、CSS、图片等资源
- 只在 HTTP/HTTPS 协议下生效；用
file://打开时，所有http-equiv都被无视
哪些 http-equiv 值现在还管用？
不是所有历史参数都还在支持。现代浏览器真正尊重的只有几个：
-
Content-Type：仅用于声明字符集，如content="text/html; charset=utf-8"。但更推荐直接用<meta charset="utf-8">——更短、更可靠、HTML5 唯一标准写法 -
Cache-Control：支持no-cache、no-store、must-revalidate等值，但要注意：no-cache≠ 不缓存，而是“每次用前必须校验”，真要禁用缓存得写全no-cache, no-store, must-revalidate -
refresh：还能触发跳转或刷新，如content="5;url=https://example.com"，但语义模糊、无障碍不友好、SEO 不认可，生产环境应优先用location.replace()或服务端重定向
Pragma（content="no-cache"）仅兼容 IE6–8；expires 已废弃，GMT 格式难写易错，现代浏览器基本忽略；Set-Cookie、Location、Window-target 等从规范到实现都不被任何主流浏览器支持，写了等于白写。
为什么写了 Cache-Control 还走缓存？
这不是 bug，是预期行为。根本原因往往不是代码写错，而是：
- 服务器响应头里明确设置了
Cache-Control，且优先级永远高于meta -
meta放在了中间或靠后位置，浏览器解析到它时，主文档请求早已发出并收到响应 - 开发时双击打开 HTML 文件（
file://协议），此时http-equiv完全不工作 - 用了
content="no-cache"就以为“绝不读缓存”，实际上它允许缓存，只是强制 revalidation；要彻底阻止存储，必须含no-store
什么时候该放弃 http-equiv，直接改服务端？
当你需要控制的行为超出单页 HTML 的能力边界时，meta 就不是解法：
- 想统一控制整个站点所有资源（JS/CSS/图片）的缓存策略 → 改 Nginx/Apache 响应头或 CDN 缓存规则
- 要设置 Cookie、重定向、CSP、Referrer-Policy 等安全相关头 → 必须由服务端返回真实 HTTP 头，
http-equiv无效 - 需精确控制跨域、MIME 类型、X-Frame-Options 等 → 同样依赖服务端，浏览器不会因
meta改变这些行为
简单说：meta http-equiv 是个有限场景下的降级手段，不是替代方案。它能救急，但撑不起生产环境的可靠性要求。
