meta charset="UTF-8" 是唯一符合HTML5规范、被所有现代浏览器早期识别的编码声明方式，必须置于内第一个非注释、非空白位置；其他写法（如小写utf-8、带空格、http-equiv形式）或位置错误（如在后、含BOM/注释前）均会导致解析失败而回退至GBK等默认编码，引发中文、emoji乱码。
meta charset="UTF-8" 是唯一可靠、必须放在 最前面的编码声明方式。其他写法或位置错误，浏览器可能忽略或误判，直接导致中文、日文、emoji 等显示为乱码。
为什么只认 meta charset="UTF-8"？
HTML5 规范强制要求：只有这种简写形式会被所有现代浏览器（Chrome/Firefox/Safari/Edge）在解析早期就识别并锁定编码。旧式写法如 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 依赖模拟 HTTP 头，实际解析时机晚、容错差，部分浏览器（尤其是移动端 WebView）会跳过它。
- 必须是
内第一个非注释标签（注释不算，但<title></title>或其他<meta>在它前面就会失效） - 不能写成
charset=utf-8（小写）——虽然多数浏览器能容错，但 W3C 验证器报错，且某些嵌入式环境严格区分大小写 - 不能加引号以外的空格，比如
charset= "UTF-8"中的空格会导致 Safari 忽略该声明
服务器响应头和 HTML meta 冲突时听谁的？
浏览器按优先级顺序决定最终编码：HTTP Content-Type 响应头 > meta charset > BOM > 自动探测。这意味着：
- 如果服务器返回
Content-Type: text/html; charset=GBK，哪怕 HTML 里写了meta charset="UTF-8"，页面仍按 GBK 解析——立刻乱码 - Node.js/Express 用户常用
res.set("Content-Type", "text/html; charset=utf-8")；PHP 用户需确认未被header("Content-Type: text/html; charset=gbk")覆盖 - 静态文件托管（如 GitHub Pages、Vercel）通常默认发 UTF-8，但 Nginx/Apache 若手动配置了
AddDefaultCharset GBK，就会覆盖 HTML 内声明
编辑器保存编码和 HTML 声明不一致怎么办？
这是最隐蔽的乱码源头：HTML 文件物理上用 GBK 保存，但 meta charset="UTF-8" 告诉浏览器“请用 UTF-8 解”，结果字节流被错误解码。
立即学习“前端免费学习笔记（深入）”；
- VS Code 默认保存为 UTF-8 无 BOM；Sublime Text 和老版 Notepad++ 可能默认用系统编码（Windows 简体中文是 GBK）
- 检查方式：用十六进制编辑器打开 HTML 文件，看开头是否为
EF BB BF（UTF-8 BOM），或FF FE（UTF-16 LE），若无 BOM 且含中文，再对照字符字节判断（如 “中” 在 UTF-8 是E4 B8 AD，在 GBK 是） - 修复动作：在编辑器中「另存为」→ 显式选「UTF-8」→ 关闭「UTF-8 with BOM」选项（BOM 可能干扰 PHP 输出或 Node.js 流）
真正起作用的永远是「文件怎么存 + 服务器怎么发 + HTML 怎么说」三者严格一致。少一个环节，meta charset 就只是个摆设。
