<meta charset="UTF-8">必须放在<title>之前，因为浏览器仅扫描前1024字节查找编码声明，若<title>含中文等非ASCII字符且<meta>在其后，则标题已被默认编码（如GBK）错误解码，后续无法回滚，导致乱码、emoji异常或JS语法错误。
为什么 <meta charset="UTF-8"> 必须放在 <title> 之前
浏览器解析 HTML 时，只扫描前 1024 字节来查找 charset 声明。如果 <meta charset="UTF-8"> 出现在 <title> 后面，而 <title> 内容本身含非 ASCII 字符（比如中文标题），那这部分内容可能已被按系统默认编码（如 Windows 上的 GBK）错误解码——后续再读到 meta 也救不回来。
常见错误现象：
-
DevTools → Network → Response Headers显示Content-Type: text/html; charset=gbk，但页面里明明写了<meta charset="UTF-8"> - 页面刚加载时标题乱码几毫秒，然后恢复正常（说明已重解码，但初始渲染已受损）
- emoji 或中文在地址栏、书签、分享摘要中显示为方块或问号
实操建议：
- 把
<meta charset="UTF-8">放在<head>最开头，紧贴<head>标签后，前面不能有任何字符（包括空格、换行、注释<!-- -->、BOM） - 用命令检查 BOM：
head -c 4 index.html | xxd，输出00000000: efbb bf...表示有 UTF-8 BOM，应避免 - VS Code 保存时选 “Save with Encoding → UTF-8”，**取消勾选 “with BOM”**
HTTP 响应头和 meta charset 谁优先
HTTP 响应头里的 Content-Type 优先级高于 meta charset。也就是说，即使 HTML 里写了 <meta charset="UTF-8">，只要服务器返回 Content-Type: text/html; charset=gbk，浏览器就按 GBK 解码——meta 直接被忽略。
典型场景：
- Nginx 默认不带 charset，但若配置了
charset gbk;，所有 HTML 都强制 GBK - 本地双击打开 HTML 文件（
file://协议），没有 HTTP 头，此时meta charset是唯一依据 - Express 中
res.set('Content-Type', 'text/html; charset=utf-8')必须在res.send()之前调用
实操建议：
- Nginx：写
charset utf-8;（小写，不能写UTF-8） - Apache：加
AddDefaultCharset UTF-8 - 检查方式：
curl -I http://your-site.com/index.html，确认响应头含charset=utf-8
charset 值大小写和拼写陷阱
charset 属性值对大小写不敏感，但 W3C 只正式认可 UTF-8 这一种写法。写成 utf8、UTF8、utf-8 虽然多数浏览器能识别，但属于非标准行为，某些严格环境（如部分 WebView、旧版邮件客户端内嵌 HTML）会失败。
容易踩的坑：
-
<meta charset="utf8">在 Android 4.4 WebView 中可能被忽略 -
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">是 HTML4 写法，HTML5 已废弃，且与<meta charset="UTF-8">共存时，后者优先 - 误写成
<meta charset=UTF-8>（漏引号），导致整个标签被浏览器忽略
实操建议：
- 统一用
<meta charset="UTF-8">，引号、大小写、连字符一个都不能错 - 不要混用：
<meta charset="UTF-8">和<meta http-equiv="Content-Type" ...>二选一，且只写一次 - 外部 CSS/JS 文件也要用 UTF-8 编码（无 BOM），否则
@charset "UTF-8";可能失效
如何验证 charset 是否真正生效
光看 HTML 源码写了 <meta charset="UTF-8"> 不代表它起作用。真实生效需要三者一致：文件编码、HTTP 响应头、meta 标签。
验证步骤：
- 在浏览器打开页面 → 右键「查看页面源代码」→ 确认
<meta charset="UTF-8">在<head>开头，且前面无空白 - 打开 DevTools → Network → 刷新 → 点击 HTML 请求 → 查看
Response Headers中Content-Type的 charset 值 - 右键页面 → 「编码」→ 看当前实际使用的是不是
UTF-8（Chrome 显示为 “Unicode (UTF-8)”） - 用
file://打开时，若乱码，基本可断定是文件本身没存成 UTF-8（无 BOM）
最隐蔽的问题往往出在构建工具上：Vite、Webpack 的 HTML 插件若未显式配置，可能把模板里的 meta charset 给删了，或注入了错误的默认值。务必检查最终生成的 HTML 文件，而不是源模板。
