http-equiv是浏览器在HTTP(S)协议下解析HTML时模拟HTTP响应头的机制，仅限<head>最前生效且优先级低于服务端头；实测有效值仅content-type、content-security-policy、refresh、default-style等少数几个。
http-equiv 是浏览器的“本地 HTTP 头开关”，但只在 HTTP(S) 协议下生效
它不是真发 HTTP 头，而是让浏览器在解析 HTML 时，把 meta 标签里 http-equiv 和 content 的组合，当作服务器返回的响应头来处理。比如 <meta http-equiv="Cache-Control" content="no-cache"> 的效果，和服务器实际返回 Cache-Control: no-cache 一致——浏览器会照着做，不走缓存（注意：是“校验后用”，不是“不存”）。
但它有硬性前提：
- 必须运行在
http://或https://协议下；用file://打开 HTML 时，http-equiv完全不触发 - 必须放在
<head>最前面；如果浏览器已开始解析或已收到服务端响应头，再写这个就晚了 - 服务端响应头永远优先级更高；比如服务器返回了
Cache-Control: public, max-age=3600，那<meta http-equiv="Cache-Control">就会被覆盖
哪些 http-equiv 值现在还真正有用
不是所有标称值都被现代浏览器支持。实测可用且仍有价值的只有这几个：
-
content-type：仅用于声明字符集，如content="text/html; charset=utf-8"；注意拼写是charset，不是encoding，错写会导致乱码 -
content-security-policy：可设基础策略，如content="default-src 'self'"；但复杂策略建议仍由服务端下发，meta不支持 nonce 或 hash -
refresh：能实现跳转或刷新，如content="5;url=https://example.com"；但对 SEO 和无障碍不友好，应优先用location.replace()或服务端 302 -
default-style：配合<link title="xxx">或<style title="xxx">指定首选样式表；需确保content值与对应元素的title完全一致
其余如 expires、Set-Cookie、Location、Date、Last-Modified 等，主流浏览器均已忽略或根本不支持。
立即学习“前端免费学习笔记（深入）”；
为什么写了 Cache-Control 还是读缓存
常见原因不是代码写错，而是执行时机或理解偏差：
- 标签没放
<head>最顶部，浏览器已根据服务端头完成缓存决策 - 用了
content="no-cache"却以为“不缓存”；实际它允许存储，只是每次用前必须向服务器校验（ETag/Last-Modified）；要彻底禁用，得写content="no-cache, no-store, must-revalidate" - 开发时用 VS Code Live Server 或其他本地服务，但响应头里自带
Cache-Control: max-age=3600，直接盖掉了meta - 页面被 Service Worker 拦截并返回缓存响应，此时
http-equiv对 SW 无影响
比 meta 更可靠的替代方案有哪些
当你要控制的行为超出 meta 能力边界，或需要更高确定性时，应绕过它：
- 字符集统一用 HTML5 原生
<meta charset="UTF-8">，更简洁、无歧义 - 缓存策略优先配置服务端（Nginx/Apache/CDN），或通过
fetch()的cache选项控制单次请求 - 跳转逻辑改用 JS：
location.replace("https://example.com")，避免refresh导致历史栈污染 - CSP 策略尽量由服务端响应头下发，
meta无法支持动态 nonce，也无法拦截内联脚本执行前的检查
最常被忽略的一点：http-equiv 只作用于当前 HTML 文档本身，对它加载的 JS、CSS、图片等子资源完全无效——那些资源的缓存、CSP、MIME 类型，都由各自请求的响应头决定。
