早期用http-equiv="Content-Type"是因90年代许多服务器不发或错发HTTP响应头，浏览器需HTML自行声明编码；HTML5改用更简洁、明确且强制前置的<meta charset="UTF-8">作为标准，http-equiv方式已被W3C标记为废弃。
为什么早期要用 http-equiv="Content-Type"
因为上世纪90年代很多 Web 服务器（尤其是静态托管、校园 FTP 站点或老旧 CMS）根本不会发 HTTP 响应头，或者默认发 Content-Type: text/html; charset=ISO-8859-1。浏览器只能靠 HTML 自己“喊话”——<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 就是让 HTML 模拟一个本该由服务器发的响应头，属于「协议层缺失时的自救机制」。
charset 属性是 HTML5 的简化替代
HTML5 直接引入了更轻量、更明确的 <meta charset="UTF-8">，它不模拟任何 HTTP 头，只声明文档自身编码。这个写法：
- 必须放在
<head>最开头（紧贴<head>开始标签后），否则可能被忽略； - 浏览器解析到它就立刻切换解码器，避免乱码；
- 不依赖 HTTP 头是否存在，对
file://协议页也有效； - W3C 明确标注
http-equiv="Content-Type"在 HTML5 中为 obsolete（已废弃），仅作兼容保留。
两者共存时谁说了算
当服务器实际返回了 HTTP Content-Type 响应头（比如 text/html; charset=GBK），浏览器优先信任它，<meta http-equiv> 和 <meta charset> 都会被跳过——这是硬性规则，不是“建议”。只有在以下情况才会 fallback 到 meta：
- HTTP 响应头里压根没带
charset参数（如只写了text/html）； - 页面通过
file://打开，没有 HTTP 头； - 某些老旧代理或中间件把响应头给吃了，但 HTML 还在。
所以现实中，<meta charset> 不是“替代”，而是“兜底中的兜底”：它只在服务器完全失能时才真正起效。
立即学习“前端免费学习笔记（深入）”；
现在还写 http-equiv="Content-Type" 会怎样
现代浏览器（Chrome/Firefox/Safari/Edge）都支持，但行为不一致：
- Chrome 会识别并当作 charset 声明处理（但已标为 deprecated 控制台警告）；
- Firefox 对
http-equiv="Content-Type"的 MIME type 部分（如text/plain）完全忽略，只取 charset； - IE 兼容模式下仍会尝试解析整条 content 字符串，但容易因空格、大小写（如
utf8vsUTF-8）出错； - 所有主流搜索引擎和 Lighthouse 工具都会报 warning，认为这是冗余且易错的写法。
真正要命的是：如果你同时写了 <meta http-equiv="Content-Type" content="text/html; charset=GBK"> 和 <meta charset="UTF-8">，而服务器又没发头，浏览器按解析顺序取第一个生效的——结果就是用 GBK 解 UTF-8 文件，满屏 。
