meta charset="UTF-8"必须是第一个子节点，前面不能有任何字节（含BOM、空格、注释、），否则浏览器仅扫描前1024字节失败即回退系统默认编码（如Windows的GBK），导致全页中文乱码。
直接说结论：meta charset="UTF-8" 必须是 里的第一个子节点，前面不能有任何字节——包括 BOM、空格、换行、注释、<script></script>，否则浏览器在前 1024 字节内找不到它，就会 fallback 到系统默认编码（Windows 是 GBK），中文立刻变“”。
为什么 meta charset 放错位置就完全失效
浏览器解析 HTML 时，只扫描文件开头最多 1024 字节来找 meta charset；一旦遇到以下任意一种情况，扫描立即终止，跳过该标签：
-
EF BB BF（BOM 字节，常见于 VS Code 默认保存为 “UTF-8 with BOM”） -
<!-- 注释 -->或任意 HTML 注释 - 开头的空行、空格、制表符（哪怕只有一个）
-
<script></script>或<link>标签出现在meta前面
结果不是“部分乱码”，而是整个页面回退到 GBK 解码——所有 UTF-8 中文都会显示为方块或问号，且 DevTools 的 document.characterSet 会返回 GBK 而非 UTF-8。
如何验证文件是否真为无 BOM 的 UTF-8
光看编辑器右下角写着 “UTF-8” 没用，必须检查实际字节。终端命令最可靠：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- Linux/macOS：
xxd -l 4 index.html—— 若输出以ef bb bf开头，说明有 BOM；应为3c 68 74 6d（即<htm>）</htm> - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3—— 若返回239 187 191，就是 BOM - VS Code：用 “Reopen with Encoding” 尝试 GBK，若中文突然可读，说明当前是 GBK 编码而非 UTF-8
修复方法：在 VS Code 中点击右下角编码 → “Save with Encoding” → 选 UTF-8（**不勾选 “with BOM”**）；Notepad++ 选 “转为 UTF-8 编码（无 BOM）”。
HTTP 响应头和 meta 必须一致，且响应头优先级更高
当页面通过 HTTP 加载（如 http://localhost），服务器返回的 Content-Type 响应头会覆盖 meta 设置。常见错误：
- Nginx 配置写成
charset=UTF-8;（错误：等号和大写）→ 正确是charset utf-8;（小写、无等号、分号结尾） - Apache 的
.htaccess写AddDefaultCharset UTF8（错误：缺短横）→ 正确是AddDefaultCharset UTF-8 - Express.js 中仅调用
res.sendFile()，没手动设头 → 必须加res.set('Content-Type', 'text/html; charset=utf-8')
验证方式：Chrome DevTools → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查看 content-type 值是否含 charset=utf-8。若此处是 charset=gbk，哪怕 meta 写对了也白搭。
最容易被忽略的是：文件实际编码、meta 值、HTTP 响应头三者必须严格一致；任何一个环节是 GBK，其余两个 UTF-8，中文就必然丢。别信编辑器界面显示，要查字节、看响应头、测 document.characterSet。
