必须置于内第一个非空白非注释子元素位置，因浏览器仅扫描前1024字节查找charset声明；若其后于、含bom或注释，则失效，导致回退至系统默认编码（如gbk/iso-8859-1）而乱码。
meta 标签没有 set 属性。防止乱码的关键是正确使用 charset 属性，且必须写成 UTF-8（大写 U、T、F，连字符，大写 8），不是 utf8、utf-8 或 UTF8。
为什么 <meta charset="UTF-8"> 放在 <title></title> 后面会失效
浏览器解析 HTML 时，只扫描前 1024 字节来找 charset 声明。如果 <meta charset="UTF-8"> 出现在 <title></title> 之后，前面已有标签、空格、注释或 BOM，就可能超出扫描范围。
- 常见错误写法：
<title>我的页面</title> <meta charset="UTF-8"> - 正确位置：必须是
内第一个非空白、非注释的子元素 - BOM（
ef bb bf）算作字节，哪怕看不见，也会挤占这 1024 字节空间 - HTML 注释
<!-- -->、空行、<script></script>标签前置都会导致识别失败
如何验证 HTML 文件实际编码是否为 UTF-8（无 BOM）
编辑器显示“UTF-8”不等于文件就是 UTF-8（无 BOM）。很多编辑器默认保存带 BOM，尤其 Windows 下的 VS Code、Notepad++。
- VS Code：右下角点击编码名称 → 选
Save with Encoding→ 严格选UTF-8（不是UTF-8 with BOM） - 命令行检查（macOS/Linux）：
head -c 4 index.html | xxd，输出含ef bb bf就有 BOM - PowerShell 检查：
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239, 187, 191就有 BOM - 清除 BOM：
sed -i '1s/^\xef\xbb\xbf//' index.html（Linux/macOS）
HTTP 响应头里的 Content-Type 为什么比 meta charset 更重要
当网页通过 HTTP 加载（http:// 或 https://），服务器返回的 Content-Type: text/html; charset=... 优先级高于任何 HTML 内声明。哪怕 meta 写得再标准，响应头是 charset=gbk，浏览器照样用 GBK 解码，中文全乱。
- 验证方式：F12 → Network → 刷新 → 找主 HTML 请求 → Headers → Response Headers → 查
Content-Type - Nginx 配置：在
server或location块中加charset utf-8;（注意小写utf-8，不能大写） - Apache 配置：加
AddDefaultCharset UTF-8（可放在.htaccess或主配置） - Node.js/Express：在
res.send()前调用res.set('Content-Type', 'text/html; charset=utf-8')
真正起作用的从来不是单点设置，而是三者同步：HTML 文件本身是 UTF-8（无 BOM）、<meta charset="UTF-8"> 在 最开头、HTTP 响应头明确声明 charset=utf-8。漏掉任意一个，乱码风险就立刻回来——尤其是开发时本地用 file:// 协议打开，没 HTTP 头，全靠 meta 和文件编码撑着，这时候 BOM 和位置错位最容易暴露问题。
