必须为内首个标签，前面不得有任何字符（含bom、空格、换行、注释），否则浏览器仅扫描前1024字节时会跳过该标签，fallback至系统默认编码（windows为gbk，linux/macos为iso-8859-1），导致中文变问号、emoji乱码或js报invalid or unexpected token。
meta charset 必须紧贴 开始，且前面不能有任何字符（包括 BOM、空格、换行、注释），否则在多数浏览器中会直接失效，退回到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1）。
为什么 meta charset="UTF-8" 放错位置就乱码
浏览器解析 HTML 时，只扫描前 1024 字节找第一个有效的 meta charset；一旦开头有 BOM（EF BB BF）、空行、<!-- --> 注释或任何非 ASCII 字符，就会跳过该标签，按 locale fallback 解析后续字节——中文立刻变问号或方块。这不是渲染问题，是解码阶段就崩了。
- VS Code 状态栏显示 “UTF-8 with BOM” → 实际文件头含 3 字节 BOM，
meta charset无效 -
\n <meta charset="UTF-8">→ 换行符算一个字符，已破坏“第一位置”要求 -
<!-- 注释 --><meta charset="UTF-8">→ 注释导致标签不是后第一个节点
如何验证文件真实编码和 BOM
别信编辑器状态栏，用命令行看原始字节：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- macOS/Linux：
head -c 4 index.html | xxd，输出含ef bb bf就有 BOM - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果为239, 187, 191即 BOM - VS Code：Ctrl+Shift+P → “Reopen with Encoding” → 选 “GBK”，若中文正常显示，说明原文件实为 GBK 编码
HTTP 响应头与 meta charset 冲突时谁生效
HTTP Content-Type 响应头中的 charset 优先级永远高于 meta charset。比如服务器返回 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了 </meta charset="UTF-8">，浏览器也会强行用 GBK 解码，结果是 UTF-8 字节流被当 GBK 解，出现乱码。
- 本地双击打开（
file://协议）→ HTTP 头完全不存在，此时只依赖meta charset和文件实际编码 - 用 Live Server 启动 → 有 HTTP 头，需同时检查响应头和文件编码是否一致
- Nginx/Apache 配置缺失时，默认可能继承系统 locale（如 CentOS 默认 ISO-8859-1），必须显式设
charset utf-8;或AddDefaultCharset UTF-8
最易被忽略的点：BOM 占用前 3 字节，直接压缩了浏览器扫描 meta charset 的有效窗口；而很多构建工具（如 html-webpack-plugin）遇到 BOM 会报 warning，但不中断流程——这意味着你看到的“构建成功”页面，可能从第一字节起就在错误解码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
