meta charset="UTF-8"必须是中第一个标签，否则浏览器仅扫描前1024字节即中断并回退至系统默认编码（如GBK或ISO-8859-1），这是90%中文乱码的主因。
meta charset="UTF-8" 必须是 中第一个标签，前面不能有任何字符（包括 BOM、空格、注释、<script></script>），否则浏览器只扫描前 1024 字节就中断，直接 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1）——这是 90% 中文乱码的真正原因。
为什么 meta charset 放错位置就失效
浏览器解析 HTML 时，并不等整个文件加载完才决定编码，而是在前 1024 字节内找 meta charset。一旦遇到以下情况，就会跳过它：
-
EF BB BF（UTF-8 BOM）出现在文件开头，把meta推到第 4 字节之后，扫描提前终止 -
<!-- 注释 --><meta charset="UTF-8">：注释占位，meta不再是第一个子节点 -
<title>页面</title> <meta charset="UTF-8">：title 标签挡在前面，meta失效 -
<meta charset="utf-8">：小写utf-8虽然 Chrome/Firefox 容忍，但某些 WebView 或 CI 工具（如 html-validate）会警告或拒绝识别
如何验证 HTML 文件实际编码是否为 UTF-8（无 BOM）
不能只看编辑器右下角显示“UTF-8”，要查真实字节：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- VS Code：打开文件 → 右键状态栏编码显示 → 选 “Reopen with Encoding” → 试 GBK，如果中文正常显示，说明当前是 GBK；再选 “Save with Encoding” → 选 UTF-8（不要勾选 “with BOM”）
- Linux/macOS：
xxd -l 4 index.html，输出应为3c 68 74 6d（即<htm>），若开头是 <code>ef bb bf就有 BOM - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191即 BOM
HTTP 响应头中的 charset 会覆盖 meta
当页面通过 http:// 或 https:// 访问时，服务器返回的 Content-Type: text/html; charset=xxx 优先级高于 meta。常见陷阱：
立即学习“前端免费学习笔记（深入）”；
- Nginx 默认不发 charset，需显式配置：
charset utf-8;（注意小写，不能写charset=UTF-8） - Apache 的
.htaccess应写：AddDefaultCharset UTF-8（大写，无等号） - Express.js：
res.set('Content-Type', 'text/html; charset=utf-8')—— 这里utf-8必须小写，UTF-8在某些 Node 版本下会被忽略 - 本地双击打开
file://时，HTTP 头无效，完全依赖meta，此时位置错误必乱码
最易被忽略的一点：CSS 和 JS 文件也必须是 UTF-8 编码，且 <link rel="stylesheet"> 和 <script src></script> 的响应头或文件本身若含 GBK 字节，会导致 <script></script> 内中文字符串报 Uncaught SyntaxError: Invalid or unexpected token，和 HTML 乱码表现一致但根源不同。
