<meta http-equiv="Content-Type"> 已被HTML5标记为过时，因浏览器优先信任HTTP响应头，且该写法易误写、仅作fallback，而<meta charset="UTF-8">更简洁可靠，须置于<head>最前并确保文件编码、HTTP头三者统一为UTF-8。
HTML 中 <meta http-equiv="Content-Type"> 已被废弃，现代项目应优先用 <meta charset> 或 HTTP 响应头控制编码，否则可能引发乱码、解析失败或 SEO 降权。
为什么 <meta http-equiv="Content-Type"> 不再推荐
这个写法模仿 HTTP 头，但 HTML5 明确将其标记为“过时（obsolete）”。浏览器实际优先信任 HTTP Content-Type 响应头；当两者冲突时（比如服务器发 text/html; charset=iso-8859-1，而页面写了 charset=utf-8），浏览器以响应头为准，<meta http-equiv> 仅作 fallback，且只在无响应头时生效（如本地打开 file:// 页面）。它还容易被误写成 content="text/html; charset=UTF-8"（少空格、大小写混用），导致部分旧浏览器完全忽略。
<meta charset> 怎么写才安全
HTML5 引入的简写形式更可靠，也更易读写：
- 必须放在
<head>最前面（最好紧贴<head>开始标签），否则浏览器可能已按默认编码（如 ISO-8859-1）解析了前面的内容 - 只接受单个属性：
<meta charset="UTF-8">—— 不要加http-equiv或content，否则无效 - 值必须是合法字符集名：
UTF-8（推荐）、ISO-8859-1、GBK等；utf8（小写）或utf-8（带连字符）在多数浏览器能识别，但规范要求大写UTF-8 - 如果 HTML 文件本身含 BOM（如 UTF-8 with BOM），
<meta charset>可能被绕过，直接按 BOM 解析 —— 保存文件时选 “UTF-8 without BOM” 更稳妥
HTTP 响应头比 meta 更权威
服务端设置的 Content-Type 响应头永远优先于任何 <meta> 标签。常见配置方式：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- Node.js/Express：
res.set('Content-Type', 'text/html; charset=utf-8')或启动时全局设app.set('view engine', 'html')并确保模板渲染前 header 已写入 - Apache：在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8 - Nginx：在
server或location块中加charset utf-8;，并确认未启用charset off; - 静态托管（GitHub Pages / Netlify）：它们默认强制
text/html; charset=utf-8，但若上传含 BOM 的 HTML 文件，仍可能触发异常解析
容易被忽略的兼容性细节
真正影响实际效果的不是语法对错，而是三者协同是否一致：
- 文件真实编码 ≠
<meta charset>声明 ≠ HTTPContent-Type中的charset - 比如用 UTF-8 编码保存文件，却写
<meta charset="GBK">，浏览器会强行按 GBK 解码，出现乱码 - 本地双击打开 HTML 文件时，没有 HTTP 头，此时
<meta charset>是唯一依据 —— 这也是测试阶段乱码高发场景 -
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">在 HTML5 中虽不报错，但 W3C 验证器会警告，且某些严格模式解析器（如部分 SSR 渲染器）可能跳过该标签
真正起效的从来不是某一行 meta，而是文件编码、meta 声明、HTTP 头三者完全对齐。只要有一处脱节，字符就可能出错 —— 尤其在非 English 环境下，这种问题往往延迟暴露，等到上线才发现中文变方块。
