必须是的第一个子元素，因浏览器仅扫描前1024字节查找该标签，开头若有BOM、注释、空格或换行即失效，导致回退系统默认编码（如Windows的GBK）引发乱码。
meta charset="UTF-8" 必须写，且必须是 的第一个子元素——这是唯一能覆盖多数乱码场景的硬性要求。其他操作都是补救或加固，不是替代。
为什么 meta charset="UTF-8" 放错位置就失效
浏览器只扫描 HTML 文件前 1024 字节找 charset 声明，一旦开头有 BOM（EF BB BF）、HTML 注释（<!-- -->）、空格、换行或零宽空格（U+200B），就可能跳过或误判。IE 和旧版 Safari 更敏感，甚至把 <title></title> 前的空白也计入偏移。
- 错误写法：
\n <!-- 注释 -->\n <meta charset="UTF-8"> - 正确写法：
<meta charset="UTF-8">（紧贴，中间无任何字符） - VS Code 中按
Ctrl+Shift+P→Change File Encoding→Save with Encoding→ 选UTF-8（明确避开 “with BOM”）
如何验证 HTML 文件真实编码是否为 UTF-8（无 BOM）
编辑器右下角显示 “UTF-8” 不等于文件真实编码。很多乱码问题根源是：你看到的是 UTF-8，但文件其实是用 GBK 存的。
- Linux/macOS：
file -i index.html应返回charset=utf-8；若为charset=iso-8859-1或charset=us-ascii，说明没存成 UTF-8 - Linux/macOS 检查 BOM：
head -c 4 index.html | xxd，输出含ef bb bf即有 BOM - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239, 187, 191，即含 BOM - Notepad++：菜单栏「编码」→「转为 UTF-8 无 BOM 格式」
file:// 协议下为什么只能靠 meta charset
双击打开 HTML 文件走的是 file:// 协议，此时 HTTP 响应头（如 Content-Type: text/html; charset=utf-8）完全不存在。浏览器只能 fallback 到 meta charset，且会严格按本地系统默认编码 fallback：Windows 是 GBK，macOS/Linux 是 ISO-8859-1 —— 这就是为什么同一份文件在不同系统上显示效果不同。
立即学习“前端免费学习笔记（深入）”；
- 验证方式：Chrome 打开 DevTools → Network → 刷新 → 点 HTML 请求 → 看 Response Headers 是否为空；若为空，
meta charset就是唯一救命稻草 - 开发时务必用 Live Server（VS Code 插件）或
npx serve启服务，让 URL 变成http://127.0.0.1:xxxx/，才能触发响应头逻辑 -
meta http-equiv="Content-Type"在 HTML5 中已废弃，且file://下完全无效，别写
UTF-8 with BOM 为什么是隐形雷
BOM（EF BB BF）是三个字节的签名，插在文件最开头。它会让 <script></script> 或 <link rel="stylesheet"> 的 src/href 路径前多出不可见字符，导致 404；更常见的是引发 Uncaught SyntaxError: Invalid or unexpected token —— 因为 JS 引擎把 BOM 当作非法起始字符。
- Webpack/Vite 构建时报
Unexpected token，先检查入口 HTML 是否含 BOM - 删除方法：VS Code 中
Save with Encoding→ 选UTF-8（不是 “UTF-8 with BOM”） - 命令行修复（Linux/macOS）：
sed -i '1s/^\xef\xbb\xbf//' index.html
真正容易被忽略的点是：三者必须同时成立——文件是 UTF-8（无 BOM）、meta charset="UTF-8" 是 第一个子元素、外部 JS/CSS 文件也必须是 UTF-8 编码。漏掉任一环，都可能在某个浏览器或某台设备上突然崩掉。
