必须将<meta charset="UTF-8">置于<head>开头、<title>之前；HTML文件须为UTF-8无BOM编码；HTTP响应头Content-Type也需设为charset=utf-8，三者缺一即可能导致中文乱码。
直接结论：只写 <meta charset="UTF-8">，且必须放在 <head> 开头、<title> 之前；HTML 文件本身也得是 UTF-8 编码（无 BOM 最稳妥），HTTP 响应头 Content-Type 也建议设为 charset=utf-8。三者缺一，中文就可能乱码。
为什么 <meta charset="UTF-8"> 必须放在 <title> 前面
浏览器解析 HTML 时，前 1024 字节内若没看到有效的 charset 声明，就会按系统默认编码（比如 Windows 上是 GBK，Linux/macOS 上常是 ISO-8859-1）开始解码。一旦开头几个字节被错误解读，后续哪怕写了 <meta charset="UTF-8"> 也救不回来——<title> 里的中文已经提前被当 GBK 解了，变成一堆 。
-
<head><title>你好</title><meta charset="UTF-8"></head>→ 失效（<title>先被错解） -
<head><meta charset="UTF-8"><title>你好</title></head>→ 有效 - 注释、BOM、空行都算“前面的内容”，
<meta charset>必须是<head>内第一个能被识别为编码声明的标签
UTF-8 和 utf8、UTF8 有区别吗
HTML 标准只认 UTF-8（连字符必须存在，大小写不敏感但推荐全大写）。虽然多数浏览器也接受 utf8 或 UTF8，但以下场景会出问题：
- 某些嵌入式 WebView（如旧版 Android WebView、IoT 设备）只严格匹配
UTF-8 - W3C 验证器报错，CI 流水线可能失败
- HTTP 响应头里写
charset=utf8违反 RFC 7231，部分代理或安全网关会拒绝或重写 - PHP 的
header('Content-Type: text/html; charset=utf8')实际无效，必须写charset=UTF-8
怎么验证 HTML 文件是不是真 UTF-8（且无 BOM）
BOM（EF BB BF）看着隐形，却会让 <meta charset> 失效——因为浏览器在找 charset 时，先读到的是这 3 个字节，而非你写的标签。
- VS Code：右下角看编码显示，点开选 “Save with Encoding” → “UTF-8”（不是 “UTF-8 with BOM”）
- macOS/Linux 终端：
head -c 4 index.html | xxd，输出不含ef bb bf才安全 - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，前三字节不能是239, 187, 191 - Sublime / Notepad++：保存时明确选 “UTF-8”（不含 BOM）
HTTP 响应头 Content-Type 和 <meta charset> 谁优先
HTTP 响应头里的 Content-Type: text/html; charset=xxx 永远优先于 <meta charset>。但注意：
- 本地双击打开 HTML 文件（
file://协议）时，没有 HTTP 响应头，<meta charset>是唯一指望 - Nginx 配置要写
charset utf-8;（小写，不能写UTF-8），且必须在server或location块里 - Node.js/Express 中用
res.set('Content-Type', 'text/html; charset=UTF-8')，不能漏掉text/html;前缀 - PHP 中
header('Content-Type: text/html; charset=UTF-8')必须在任何输出之前调用，否则因 BOM 或空格导致 header 失败
最容易被忽略的点：开发时在本地反复双击测试，一切正常；一上服务器，HTTP 响应头没配或配错，立刻乱码——因为本地没走 HTTP，根本没触发那个“谁优先”的逻辑。
