必须紧贴 开头、 之前，且文件本身必须是 utf-8 编码（推荐带 bom），否则浏览器仅扫描前 1024 字节寻找编码声明，错过则 fallback 至系统默认编码（如 gbk 或 iso-8859-1），导致乱码、emoji 显示为方块、js 报 invalid or unexpected token 错误；若文件实际为 gbk 却声明 utf-8，或 http 响应头 content-type 指定 gbk，则 meta 失效，解析必然错误。
meta charset="UTF-8" 必须放在 开头、<title></title> 之前，且文件本身必须是 UTF-8 编码（推荐带 BOM），否则极易出现乱码、脚本报错或 emoji 显示为方块——这不是浏览器 bug，而是编码探测机制的必然结果。
为什么 meta charset="UTF-8" 必须紧贴
浏览器解析 HTML 时，只扫描前 1024 字节来寻找字符集声明。一旦错过这个窗口，就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1）：
- 如果
<title>你好</title>出现在meta前，而文件是 UTF-8 编码，“你好”两个汉字会被错解为 4 个 Latin-1 字符，标题直接变乱码 - 如果前面有注释、空格或换行，只要总长度 ≤ 1024 字节且没超文本内容，通常仍可接受；但
<script></script>、<style></style>或任何含中文/emoji 的文本节点都算“文本内容”，必须在其之前 - 旧版 IE 甚至会忽略非首个位置的
meta charset，直接跳过
文件实际编码和 meta charset 不一致时会发生什么
声明和真实编码不匹配，是乱码最常见根源：
- HTML 文件实际是 GBK 编码，却写
meta charset="UTF-8"→ 浏览器强行按 UTF-8 解码 GBK 字节流，出现030103类乱码，JS 中字符串也会触发Uncaught SyntaxError: Invalid or unexpected token - 文件是 UTF-8（无 BOM），但服务器响应头返回
Content-Type: text/html; charset=GBK→ HTTP 响应头优先级高于meta，整个页面按 GBK 解码，meta彻底失效 - VS Code 默认保存为 UTF-8（无 BOM），但某些旧环境（如部分 WebView）对无 BOM 的 UTF-8 识别不稳定，建议手动选 “UTF-8 with BOM”
如何验证当前 HTML 文件的编码状态
不能只看编辑器右下角显示，要查真实字节：
- Linux/macOS：
head -c 3 index.html | xxd，输出ef bb bf表示有 UTF-8 BOM；file -i index.html查 MIME 类型和编码 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239, 187, 191，即为 BOM - VS Code：右下角编码显示旁点箭头 → “Reopen with Encoding” 可强制用 GBK 打开，若中文正常显示，说明文件实为 GBK；再选 “Save with Encoding” → UTF-8（务必勾选 “with BOM”）
- 浏览器 DevTools → Elements 标签页，确认
meta charset确实在第一个子节点位置
UTF-8 拼写必须全大写带连字符，且仅此一种合法形式
WHATWG HTML 规范只认可 "UTF-8"（U/T/F/-/8 全大写，连字符不可省略，末尾数字不可缺）：
-
meta charset="utf-8"、meta charset="UTF8"、meta charset="utf8"都不符合规范，虽多数浏览器能容错，但 html-validate 等 CI 工具会直接报错 -
meta http-equiv="Content-Type" content="text/html; charset=UTF-8"是 HTML5 之前的老写法，兼容性好但冗余，新项目无需使用 - 不要混用：同一项目中 CSS、JS 文件也必须统一为 UTF-8（带 BOM 更稳妥），否则
@charset "UTF-8";或 JS 字符串仍可能出问题
真正卡住人的从来不是“怎么写”，而是“文件到底是什么编码”和“HTTP 响应头有没有覆盖它”——这两点不验清楚，meta charset 写得再标准也没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
