是浏览器解析 HTML 的第一道指令，失效则90%中文乱码已注定；它必须位于 开头、无 BOM/注释/空格/前置标签，且值严格为 UTF-8；HTTP 响应头 Content-Type: text/html; charset=utf-8 优先级更高，本地 file:// 协议下仅依赖该 meta；CSS/JS 等外部资源也须同为 UTF-8（无 BOM）。
meta charset 不是“可选配置”，而是浏览器解析 HTML 的第一道指令。它失效时，90% 的中文乱码就已注定——不是文字本身坏了，是浏览器从第一个字节就开始读错。
为什么 meta charset="UTF-8" 放在
浏览器只扫描 HTML 前 1024 字节找 charset 声明，且必须是**可识别的纯 ASCII 字符流**。以下任意一种都会让它跳过：
- BOM（
ef bb bf）出现在前——VS Code 默认“UTF-8 with BOM”就是元凶 -
<!-- 注释 -->或空格、换行写在<meta charset>前 -
<title></title>标签比<meta charset>更靠前（哪怕只差一行） - 写了
utf8、UTF8、utf-8等非标准值——W3C 只认UTF-8
验证方法：head -c 4 index.html | xxd 输出含 ef bb bf 就有 BOM；用 VS Code 右下角编码栏确认是否显示 “UTF-8 with BOM”。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
HTTP 响应头里的 Content-Type 和 meta charset 谁说了算？
服务器响应头优先级永远高于 HTML 内部声明。如果 curl -I your-page.html 返回 Content-Type: text/html; charset=gbk，哪怕你写了十遍 meta charset="UTF-8"，浏览器也按 GBK 解码。
- Nginx 配置必须写
charset utf-8;（小写，不能大写或带连字符） - Apache 用
AddDefaultCharset UTF-8，别写成GB2312 - Node.js/Express 中，
res.set('Content-Type', 'text/html; charset=utf-8')必须在res.send()之前调用 - 本地双击打开（
file://协议）时无响应头，此时meta charset是唯一依据，BOM 失效风险最高
怎么一次性验证三者是否真正统一？
打开浏览器开发者工具 → Network → 刷新页面 → 找到主 HTML 请求 → 看 Response Headers 里的 Content-Type；再右键“查看页面源代码”，确认 <meta charset="UTF-8"> 是 的第一个子标签；最后用编辑器检查文件实际编码（VS Code 右下角点开选 “Save with Encoding → UTF-8”，明确避开 “with BOM”）。
最容易被忽略的是：CSS、JS、模板文件也必须同为 UTF-8（无 BOM），否则引入的外部资源一旦含中文，照样触发二次乱码——这不是 meta charset 能管的事。
