必须置于最开头、任何非ASCII字符（含、注释、BOM、空格、emoji）之前，否则浏览器仅扫描前1024字节且只识别ASCII范围内的meta标签，一旦遇到非ASCII内容即跳过该声明，fallback至系统默认编码（Windows为GBK，macOS/Linux为ISO-8859-1），导致中文乱码、emoji异常、JS语法错误等问题。
meta charset="UTF-8" 必须放在 开头、任何非 ASCII 字符（包括 <title></title>、注释、BOM、空格、emoji）之前，否则浏览器可能 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），直接导致中文乱码。
为什么 meta charset="UTF-8" 放错位置就失效
浏览器解析 HTML 时，只扫描前 1024 字节，并且只识别 ASCII 范围内的字符来匹配 meta charset。一旦在这段范围内出现非 ASCII 字符（比如中文 <title></title>、注释 <!-- -->、BOM \uFEFF 或换行后缩进空格），就会跳过该标签，转而用系统默认编码加载整页。
-
<title>活动页</title> <meta charset="UTF-8">→ 失效（<title></title>含中文，已超 ASCII） -
<!-- 注释 --><meta charset="UTF-8">→ 失效（注释不是 ASCII） -
\n <meta charset="UTF-8">→ 失效（换行+空格虽是 ASCII，但某些旧 WebView 会误判） - ✅ 正确：
<meta charset="UTF-8"> <title>活动页</title>
charset 的值必须严格写成 "UTF-8"
IANA 官方注册名只认 UTF-8（U/T/F 大写，8 是数字，中间短横不可省略）。写成 "utf8"、"utf_8"、"UTF8" 或 "unicode" 在部分环境（如 Safari WebView、html-webpack-plugin、某些嵌入式浏览器）中会被忽略，退回到 fallback 编码。
- ❌
<meta charset="utf8">—— Chrome 可能容忍，但不保证 - ❌
<meta charset="UTF8">—— 缺短横，非标准 - ✅
<meta charset="UTF-8">—— 唯一推荐写法
文件保存编码必须和 meta 声明一致
VS Code 默认新建文件是 UTF-8，但打开一个 GBK 编码的旧文件后，再保存，很可能仍存为 GBK —— 此时即使写了 meta charset="UTF-8"，浏览器也会把 GBK 字节流当 UTF-8 解，每个中文变两个乱码字（如 “你好” 显示为 “浣犲ソ”）。
立即学习“前端免费学习笔记（深入）”；
- VS Code：用 File → Save with Encoding → UTF-8（注意：不要选 “UTF-8 with BOM”，BOM 会出现在
<meta>前，干扰解析） - 验证方法：
file -i index.html（Linux/macOS）或 PowerShell 中Get-Content index.html -Encoding Byte | Select -First 3，确认输出不含ef bb bf - 别依赖编辑器自动识别：Sublime/Notepad++ 有时会误判 GBK 文件为 UTF-8，手动指定编码再重开更可靠
HTTP 响应头比 meta 更优先，但别指望它兜底
如果服务器返回 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了 meta charset="UTF-8"，浏览器也以响应头为准 —— 这是规范行为，不是 bug。
- Nginx 配置：在
server或location块加charset utf-8; - Express：用
res.set('Content-Type', 'text/html; charset=UTF-8') - 静态托管（Vercel/GitHub Pages）：默认发 UTF-8，但前提是你的文件本身是 UTF-8 编码
- ⚠️ 关键点：响应头和
meta、文件实际编码三者必须完全一致，缺一不可
BOM 是最隐蔽的坑：它藏在文件开头、看不见，却能让 meta charset 彻底失效；而编辑器里“UTF-8 with BOM”的选项，恰恰是多数人踩坑的第一步。
