必须紧贴开头，因浏览器仅扫描前1024字节查找该标签；若此前存在、注释、空格、BOM或等，将触发系统默认编码（如Windows的GBK），导致中文乱码、emoji异常或JS语法错误。
meta 标签的 charset 属性必须写成 <meta charset="UTF-8">，且必须出现在 开始后、任何其他标签（包括 <title></title>、<script></script>、注释、空格）之前。其他写法基本都不可靠。
为什么 charset="UTF-8" 必须放在
浏览器解析 HTML 时，只扫描前 1024 字节来查找 <meta charset>；一旦遇到非 ASCII 字符（比如中文标题、emoji、BOM 或注释），就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），后续所有内容都可能乱码或报错。
常见失效位置：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
<title>我的页面</title> <meta charset="UTF-8">——<title></title>已含非 ASCII，meta失效 -
<!-- 注释 --><meta charset="UTF-8">—— 注释占用字节，可能挤出有效扫描范围 -
<script>console.log("你好")</script><meta charset="UTF-8">——<script></script>内容提前触发 fallback
charset 值写成 "utf-8"、"UTF8" 或 "utf8" 会怎样？
HTML5 规范只认可 "UTF-8"（U/T/F 大写，中间连字符，末尾数字 8，无空格）。其他写法虽在部分浏览器中能“碰巧”工作，但存在明确风险：
-
charset="utf-8"：W3C 验证器会警告，CI 流水线（如 html-validate）可能直接报错 -
charset="UTF8"或charset="utf8"：Android WebView、某些旧版 Electron、Node.js 模板引擎可能完全不识别，fallback 到系统编码 -
charset=UTF-8（无引号）：HTML5 允许，但易被模板引擎或预处理器误解析，统一用双引号更稳妥
文件保存编码、HTTP 响应头和 meta charset 不一致怎么办？
三者必须全部为 UTF-8，否则必然出问题。优先级是：HTTP Content-Type 头 > meta charset > 系统 fallback。
- 若服务器返回
Content-Type: text/html; charset=GBK，即使写了<meta charset="UTF-8">，浏览器仍按 GBK 解析——需改 Nginx/Apache 配置或 PHP 的header() - 若文件实际保存为 GBK，但
meta写了 UTF-8，浏览器会用 UTF-8 解码 GBK 字节，显示为 - 验证方法：
xxd -l 3 index.html查 BOM（EF BB BF 表示 UTF-8 with BOM，应避免）；Chrome DevTools → Network → Response Headers 看Content-Type
最容易被忽略的是：哪怕你写对了 <meta charset="UTF-8">，只要文件开头有 BOM、 前有空格/换行/注释、或服务器头与之冲突，它就形同虚设。真正起效的只有那唯一一个、紧贴 开始、无前置干扰的 <meta charset="UTF-8">。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
