<meta charset="UTF-8"> 必须置于 <head> 最开头，因浏览器边下载边解析，若此前出现中文或 emoji，会按默认编码（如 ISO-8859-1）错误解码致乱码且不可逆；位置错、大小写错或文件实际编码不匹配均会导致失效。
meta charset 必须放在 最开头
浏览器解析 HTML 时，会从文件开头逐字节读取，一旦遇到非 ASCII 字符（比如中文、emoji），而此时还没看到 <meta charset="UTF-8">，就会按系统默认编码（如 Windows 上的 GBK 或旧版 ISO-8859-1）去解码——结果就是乱码，且后续 <meta charset> 即使存在也救不回来。
常见错误写法：<head><title>我的页面</title><meta charset="UTF-8"></head>。这里 <title> 已经触发了早期解码，中文标题很可能已损坏。
正确顺序必须是：<head><meta charset="UTF-8"><title>我的页面</title></head>。哪怕只有一行注释或空格在 <meta> 前，都可能影响部分浏览器（尤其是 IE）的识别。
UTF-8 要大写，不能写成 utf8 或 utf-8
charset 属性值不是“随便能通”的字符串，而是 HTML5 规范明确定义的字符集名称。规范只接受 "UTF-8"（全大写 U、T、F，中间短横，数字 8）。
立即学习“前端免费学习笔记（深入）”；
以下写法均无效或不可靠：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
charset="utf8"—— 缺少短横，某些旧浏览器会忽略 -
charset="utf-8"—— 小写 u，不符合规范，Chrome/Firefox 虽常兼容，但 Safari 或 Edge 可能降级为默认编码 -
charset="UTF8"—— 缺少短横，IE 会直接失效 -
charset="unicode"—— 完全非法，无任何浏览器支持
务必严格使用 <meta charset="UTF-8">，大小写和符号一个都不能错。
编辑器保存编码必须和 meta 值一致
<meta charset="UTF-8"> 是“告诉浏览器怎么读”，但前提是文件本身真是 UTF-8 编码。如果用记事本保存为 GBK，再写 charset="UTF-8"，浏览器就会用 UTF-8 去解 GBK 字节流——必然乱码。
关键检查点：
- VS Code：右下角状态栏点击编码名称 → 选
Save with Encoding→UTF-8（**不要选 UTF-8 with BOM**，BOM 会干扰 IE 和部分构建工具） - Sublime Text：
File → Save with Encoding → UTF-8 - Eclipse：Preferences → Web → HTML Files → Encoding → 选
UTF-8 - 确认方式：用十六进制编辑器打开文件，开头不应有
EF BB BF（即 BOM）
HTTP 响应头比 meta 更优先，但本地 file:// 协议下它失效
当 HTML 通过 HTTP 服务器（如 Nginx、Express、Python http.server）返回时，响应头中的 Content-Type: text/html; charset=UTF-8 会覆盖 <meta charset>。也就是说，即使 HTML 里写了 charset="GBK"，只要响应头是 charset=UTF-8，浏览器仍按 UTF-8 解析。
但注意：file:// 协议（直接双击打开 HTML 文件）没有 HTTP 响应头，此时 <meta charset> 是唯一依据。很多本地调试时乱码，就是因为忘了这层限制。
验证是否生效的最快方法：document.characterSet 在控制台输出应为 "UTF-8"；同时 Network 面板中该 HTML 请求的 Response Headers 里 Content-Type 字段也应含 charset=UTF-8（线上环境），二者缺一不可。
