<meta charset="UTF-8">必须置于<head>最开头、任何非ASCII字符（含BOM、注释、<title>、空格、换行）之前，否则浏览器仅扫描前1024字节时会跳过该标签，fallback至系统默认编码（如Windows的GBK），导致中文、emoji乱码及JS报Invalid or unexpected token。
meta charset="UTF-8" 必须放在 <head> 开头、任何非 ASCII 字符（包括 BOM、注释、<title>、空格、换行）之前，否则浏览器会跳过它，fallback 到系统默认编码（如 Windows 的 GBK），直接导致乱码或 JS 报 Invalid or unexpected token。
为什么 meta charset 放错位置就失效
浏览器解析 HTML 时，只扫描前 1024 字节寻找 <meta charset>，且仅识别 ASCII 范围内的字符。一旦开头出现：
- BOM（
EF BB BF）—— Notepad++ 默认保存为 UTF-8-BOM 时就会插入 - 注释
<!-- ... -->—— 即使是空注释也含非 ASCII 字符 -
<title>或其他标签在<meta charset>前 - 开头有空行、缩进、中文空格或 emoji
都会让该标签被忽略，浏览器立即按 GBK / ISO-8859-1 解析后续字节，JS 字符串、emoji、中文标题全崩。
meta charset="UTF-8" 的写法必须严格
IANA 注册的唯一合法值是 "UTF-8"（全大写 U/T/F，数字 8，中间短横线）：
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：
<meta charset="UTF-8"> - ❌ 错误：
<meta charset="utf8">（Chrome 可能容忍，但 WebView/Safari/html-webpack-plugin 会 fallback） - ❌ 错误：
<meta charset="UTF8">、<meta charset="utf_8">、<meta charset="unicode"> - ❌ 错误：
<meta charset="UTF-8"/>（XHTML 自闭合写法在 HTML5 中不必要，且部分旧解析器可能误判）
如何验证 charset 是否真正生效
不能只看 <meta> 标签有没有写——要三处交叉验证：
- DevTools → Network → 刷新页面 → 查看 HTML 请求的
Response Headers中Content-Type是否为text/html; charset=utf-8 - 控制台执行
document.characterSet，返回值必须是"UTF-8" - 终端执行
file -i your-page.html（macOS/Linux）或Get-Content your.html -Encoding Byte | Select -First 3（PowerShell），确认文件实际编码是 UTF-8 且**无 BOM**（BOM 会干扰<meta>识别）
三者只要有一个不一致，页面就存在隐性乱码风险；尤其是 BOM 和 HTTP 响应头冲突时，浏览器优先信响应头，meta 彻底被无视。
