http-equiv 这一族 meta 标签：七个取值里，哪些还有用、哪些该换掉
http-equiv 是让 meta 元素冒充 HTTP 响应头的属性，而大家还往里塞的大多数取值什么都不做。HTML 标准定义了七个：四个还有作用，两个是 Google 真正会读的。这一章是一张路由表。
http-equiv 是让 <meta> 元素冒充一个 HTTP 响应头的属性，而大家还往里塞的大多数取值，其实什么都不做。HTML 标准一共定义了七个：四个在当前浏览器里还有作用，两个是 Google 文档真正会读的，其余的每个现代浏览器都直接忽略。这一章是一张路由表——哪些取值值得留、该换成什么写法。
读这篇前
你需要能改页面的 <head>，也要知道你的服务器能不能发响应头。如果你用的是静态托管，有几个设置根本没有你能碰到的响应头，那么 meta 写法就是你唯一的选择。下面默认两条路你都能走，并且在需要选的时候告诉你差别在哪。
要抓住的概念只有一个：pragma 和 metadata 的区别。name 属性的 meta 标签是在描述这个页面；http-equiv 属性的 meta 标签是要求浏览器表现得像服务器发过某个响应头。这个差别，就是为什么长得差不多的标签，命运差这么远。
http-equiv 到底在做什么
这个属性名是 HTTP equivalent（HTTP 等价物）的缩写。浏览器解析到 <meta http-equiv="refresh"> 时，会按处理 Refresh 响应头的方式来处理它。标准把这一类叫 pragma directive（pragma 指令），并且明确列了有哪些；不在这张列表上的取值，根本不是指令，而是解析器会跳过的一个属性。
http-equiv 不是「从 HTML 里设置任意响应头」的通用办法。它是一张很短、封闭的七项指令表，而其中只有前两项会被任何给站点做索引的东西读到。
这张封闭列表就是本章的全部内容。HTML 标准说这个属性「is an enumerated attribute with the following keywords and states」，MDN 把同一件事压成一句：「Only a subset of the HTTP headers are supported as http-equiv values.」
七个取值里，哪些还有用
一共七个取值。四个会被当前浏览器执行，一个只为已经退场的浏览器存在，两个是明确无效的。「是否合规」那一列是标准自己给的判定。
| 取值 | 合规 | 做什么 | 该用什么 |
|---|---|---|---|
| content-type | 是 | 声明字符编码 | <meta charset> |
| refresh | 是 | N 秒后刷新或跳转 | 服务端 301 |
| content-security-policy | 是 | 给本文档强制一条 CSP | CSP 响应头 |
| default-style | 是 | 指定默认样式表集合的名字 | 没有替代；极少需要 |
| x-ua-compatible | 是 | 旧版 IE 的渲染模式 | 什么都不用；删掉这行 |
| content-language | 否 | 设置默认语言 | lang 属性 |
| set-cookie | 否 | 什么都不做，设计上就被忽略 | Set-Cookie 响应头 |
这张表里有两行最费时间。set-cookie 是最清楚的：标准原文写着这个 pragma「is non-conforming and has no effect. User agents are required to ignore this pragma.」这样写的 cookie 从来没有被设上过，任何浏览器、任何年份都没有。x-ua-compatible 是另一个：它当年是为了让旧版 Internet Explorer 规矩一点，MDN 现在直接写「User agents now ignore this pragma」，而它针对的那些浏览器早已停止支持。
Google 文档真正会读的，只有两个
Google 有一份它支持的 meta 标签清单，七个取值里只有两个在上面。两个都写在那份「Meta tags and attributes that Google supports」里，我们 2026-09-14 实取时它的页脚标注 Last updated 2025-12-10 UTC。
| 取值 | Google 的原话 | 实际效果 |
|---|---|---|
| content-type | 定义「the page's content type and character set」 | 让 Google 读到你的编码 |
| refresh | 「sometimes used as a simple form of redirection」 | 会跟随，但不推荐 |
charset 那一行附带一条值得原样抄走的格式要求：给值加引号。Google 那页写的是「surround the value of the content attribute in the http-equiv meta tag with quotes — otherwise the charset attribute may be interpreted incorrectly」。现代写法根本不会有这个问题，因为 <meta charset="utf-8"> 只有一个值，没有可被解析错的地方。
refresh 那一行是 Google 会跟随、但劝你别用的跳转。它写的是 meta refresh「is not supported by all browsers and can be confusing to the user. We recommend using a server-side 301 redirect instead」。Google 另一页讲重定向的文档确实把 meta refresh 列进了支持的方法里，和 HTTP 301、308 在同一张表，只是排位在它们下面，JavaScript 又在更下面。
按这个顺序做
四步，每一步都有一个能自己验证的完成标志。整套走一遍每个模板几分钟，而且值得对所有页面模板做一遍，而不是一页一页来。
- 把你所有模板里的 http-equiv 标签列出来。查源码，不要查渲染后的页面，否则会漏掉条件分支。完成标志：拿到的是取值的全集，不是抽样。
- 逐个对上面那张七行表。不在列表上的就是无效负担，而两个不合规的取值要最先删。完成标志：每条标签旁边都写上了「留」或「换」。
- 对每个「换」，确认你能不能发真正的响应头。静态托管可能不行，服务器或 CDN 一般可以。完成标志：每个取值你都清楚响应头这条路通不通。
- 先改一个模板，再抓一次渲染后的页面确认。完成标志：旧标签从 HTML 里消失了，换成响应头的那几个能在响应里看到。
# 模板实际发出了哪些
grep -rn 'http-equiv' templates/ | sed 's/.*http-equiv="\([^"]*\)".*/\1/' | sort | uniq -c
# 浏览器实际收到什么，连响应头一起看
curl -sI https://example.com/ | grep -iE 'content-type|content-security-policy|set-cookie'
# HTML 自己写了什么
curl -s https://example.com/ | grep -io 'http-equiv="[^"]*"'交付物：一张路由表
把这张表和上面那张七行表放在一起。它回答的是找到标签之后唯一重要的问题——每个意图到底该住在哪里。每一行都是把一个设置从 HTML 挪到响应里：HTML 到得晚、还可能被跳过，响应在正文之前就到达，解析器跳不过去。
| 你想做什么 | meta 写法 | 优先用 |
|---|---|---|
| 声明编码 | content-type | <meta charset> 或响应头 |
| 让页面跳转 | refresh | HTTP 301 |
| 发一条安全策略 | content-security-policy | CSP 响应头 |
| 设一个 cookie | set-cookie | Set-Cookie 响应头 |
| 声明页面语言 | content-language | <html> 上的 lang |
| 缓存这份响应 | cache-control | Cache-Control 响应头 |
最后一行根本不是七个取值之一，而这正是重点。http-equiv="cache-control" 和 http-equiv="pragma" 在老模板里很常见，两个都不在标准的 states 列表里。它们不是指令，只是长得像指令的字符串。缓存由 Cache-Control 响应头决定，而一个 meta 标签影响不了一份已经发出去的响应。
做错了会怎样，以及怎么发现
三种失败覆盖了绝大多数情况，而且三种都不会报错。只有看对地方才看得出来。
- 一个永远不会触发的跳转。延迟不为零的
refresh是个计时器，不是跳转；计时器到点之前就离开的爬虫，看到的是原来那页。Google 会跟随这个标签，但它明确让你用 301，所以解法是换掉，而不是把秒数调小。 - 编码从错的地方被读走。
content-type标签如果content值没加引号，charset 可能被解析错，浏览器只能靠猜。症状是编辑器里看着正常的页面出现乱码。换成<meta charset>，这个歧义就没有了。 - 标签在、看着也合法，但完全无效。这就是
set-cookie和x-ua-compatible的情况。没有东西失败，因为本来就没有东西在工作；那行什么都不做，而且会一直什么都不做，直到有人把它删掉。
有一条边界要写清楚：本章只讲 HTML 标准定义的那几个取值。某个浏览器厂商偷偷认、但标准没列的取值不在范围内，MDN 自己的附注也是这么说的——「some browsers process additional headers that are not listed above」，而因为无法识别的取值会被忽略，「this can lead to inconsistent behaviour」。那些厂商专属的取值我们一个都没测，所以这一章不推荐任何一个。
常见问题
http-equiv 现在还有用吗
有用，它是一个有七个定义取值的属性，其中两个是 Google 会读的。没用的是那个「从 HTML 里设置任意响应头」的普遍想法。这张列表是封闭的，而且已经封闭很多年了。
该用 meta refresh 还是 301
每次都选 301，除非你的托管根本没给你发状态码的办法。Google 的重定向文档把 meta refresh 列为支持的方法，但排在 HTTP 状态码下面，它的 meta 标签文档则直接推荐服务端 301。
为什么我的模板里还留着 x-ua-compatible
因为它是当年 Internet Explorer 需要的时候加进去的，之后没人删。当前浏览器忽略这个 pragma，它针对的那个浏览器也已经退场，所以这行现在是惰性的。删掉它除了让 head 变短，不会有任何变化。
能用 meta 标签发 Content-Security-Policy 吗
可以，标准也定义了这个 state。但响应头仍然是更好的位置，因为它在文档正文之前到达，而且能覆盖 meta 够不到的响应。x-ua-compatible 那次实测正好说明一行废弃的 meta 能在模板里活多久；网页编码那次实测讲的则是唯一一个真正值得留下的取值。
删掉这些标签会不会伤到什么
删惰性的那几个，不会。对那两个还有作用的，判据是等价的响应头或属性有没有先就位。如果你在没有 <meta charset>、也没有响应头的情况下删掉 content-type，浏览器就得猜你的编码，那是真的回退。AI 爬虫可达性检查会告诉你一个非浏览器客户端收到的是什么，那是快速抓出「编码已经没人读得出来」的办法。
本文属于 QueryWin 实操手册 · 第 2 阶
