必须放在最前面，因为浏览器仅扫描前1024字节查找，若被注释、script、bom或阻挡，将fallback至系统默认编码（如gbk/iso-8859-1），导致中文、emoji及js字符串解析错误。
meta charset="UTF-8" 必须写在 开头、<title></title> 之前，且只能出现一次；写错位置、拼写错误或文件编码不匹配，都会导致 emoji、中文甚至 JS 字符串直接报错。
为什么 meta charset="UTF-8" 必须放在
浏览器解析 HTML 时，只扫描前 1024 字节来查找 meta charset；如果它被注释、<script></script>、空格或 BOM 挡住，就会跳过，转而用系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1）解码——<title>你好</title> 就可能显示成 好你 或乱码符号。
- 正确顺序：
<meta charset="UTF-8"> <title>...</title> - 错误示例：
<title>...</title> <meta charset="UTF-8">（<title></title>已触发解析，来不及改编码） - BOM（
EF BB BF）若出现在前，也会让 <code>meta charset失效
charset 的值到底该怎么写？
HTML5 规范只认可 "UTF-8"（全大写 U/T/F，中间短横，末尾数字 8，无空格）；其他写法如 "utf-8"、"UTF8"、"utf8" 虽然多数浏览器能容错，但会被 W3C 验证器、CI 工具（如 html-validate）直接报错。
- ✅ 正确：
<meta charset="UTF-8"> - ❌ 错误：
<meta charset="utf-8">（小写）、<meta charset="UTF8">（缺短横）、<meta charset="utf8">（缺短横+小写） - ⚠️ 不推荐：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（旧式写法，IE 兼容性好但冗余，现代项目应避免）
文件实际编码和 meta charset 不一致会怎样？
声明只是“告诉浏览器怎么读”，不是“把文件转成 UTF-8”；如果 HTML 文件本身是 GBK 编码，却写了 meta charset="UTF-8"，浏览器会强行按 UTF-8 解码 GBK 字节流，结果就是中文变一堆问号或乱码符号（比如 ä½ å¥½），JS 中的字符串也会触发 Uncaught SyntaxError: Invalid or unexpected token。
- VS Code：右下角查看当前编码 → 点击 → “Save with Encoding” → 选
UTF-8（注意：不要选UTF-8 with BOM） - 命令行验证：
head -c 4 index.html | xxd，输出不含ef bb bf才是纯 UTF-8 - Notepad++：菜单栏“编码” → “转为 UTF-8 无 BOM 格式”
HTTP 响应头里的 Content-Type 和 meta charset 冲突了怎么办？
HTTP 响应头优先级高于 meta charset；如果服务器返回 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了 meta charset="UTF-8"，浏览器也按 GBK 解析——此时乱码与 meta 无关，得改服务端配置。
- Nginx：在
server或location块加charset utf-8; - Apache：.htaccess 中加
AddDefaultCharset UTF-8 - PHP：开头加
header('Content-Type: text/html; charset=UTF-8'); - 本地测试（file://）时，HTTP 头不存在，
meta charset是唯一依据
真正容易被忽略的是三者必须同时对齐：HTML 文件真实编码、meta charset 声明、HTTP 响应头中的 charset。少一个，就可能让一个 emoji 在控制台报错，或让表单提交的中文变成乱码字节流。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
