必须放在最开头，且HTML文件为UTF-8无BOM、服务器响应头含charset=utf-8——三者缺一不可；浏览器仅扫描前1024字节找，若被注释、空格或阻挡即失效，必然乱码。
直接说结论：<meta charset="UTF-8"> 必须放在 的最开头，且 HTML 文件本身必须保存为 UTF-8 无 BOM 格式，服务器响应头也得带 Content-Type: text/html; charset=utf-8 —— 三者缺一不可，否则乱码不是“可能”，是“必然”。
为什么 <meta charset="UTF-8"> 必须是
浏览器解析 HTML 时，会在读取前 1024 字节就尝试确定编码。如果 <meta charset> 被挤在 <title></title> 后面、或者前面有注释/空格/JS 模板语法（比如 ），它就来不及生效。IE 和某些 WebView 尤其敏感。
- 错误写法：
<!-- 注释 --><title>首页</title> <meta charset="UTF-8"> - 正确写法：
<meta charset="UTF-8"> <title>首页</title> - 模板引擎（如 EJS、Django）中，确保
<meta charset>不被任何逻辑块包裹或延迟渲染
编辑器保存为 UTF-8 无 BOM 是什么操作？
BOM（Byte Order Mark）是三个隐藏字节 EF BB BF，Windows 记事本和部分 Sublime Text 默认加它；VS Code 默认不加，但右下角状态栏会显示当前编码。BOM 会导致 JS 报错 Uncaught SyntaxError: Invalid or unexpected token，尤其在 <script></script> 内联代码或 <link rel="stylesheet"> 的 href 值开头。
- VS Code：右下角点击编码名 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - Sublime Text：File → Save with Encoding → UTF-8
- Notepad++：编码 → 转为 UTF-8 无 BOM 格式
- 验证方式：用命令行
file -i your.html或十六进制查看器确认开头没有ef bb bf
服务器响应头的 Content-Type 为什么能覆盖 <meta>？
HTTP 协议规定：响应头中的 Content-Type 优先级高于 HTML 内任何 <meta>。哪怕你写了 <meta charset="UTF-8">，只要服务器返回的是 Content-Type: text/html; charset=iso-8859-1，浏览器就按 ISO-8859-1 解析 —— 中文直接变方块或问号。
立即学习“前端免费学习笔记（深入）”；
- Nginx：在
http/server/location块中加charset utf-8; - Apache：在
.htaccess或虚拟主机配置里加AddDefaultCharset UTF-8 - Node.js（Express）：
res.set('Content-Type', 'text/html; charset=utf-8')，或更稳妥地用res.send(htmlString)（它默认加 charset） - 静态托管（GitHub Pages、Vercel）：通常默认 UTF-8，但需检查 Network 面板的 Response Headers 确认
最容易被忽略的点：CSS 和 JS 文件也得是 UTF-8 无 BOM，且不能靠 <script charset="UTF-8"></script> 补救 —— HTML5 已废弃该属性，它无效。所有文本资源统一用 UTF-8，才是真·统一。
