<meta charset="UTF-8">必须紧贴<head>开头，前面不能有任何字节（含BOM、空格、注释），否则浏览器仅扫描前1024字节失败而fallback至系统默认编码（如Windows的GBK），导致中文显示为“0100”类乱码。
<meta charset="UTF-8"> 必须紧贴 <head> 开始，且前面不能有任何字节（包括 BOM、空格、换行、注释），否则浏览器会 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 常为 ISO-8859-1），直接导致中文显示为 0100 类乱码。
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器解析 HTML 时只扫描前 1024 字节找 <meta charset>，一旦遇到 BOM（EF BB BF）、<!-- 注释 -->、空行或 <title> 等标签挡在前面，就会跳过它。此时即使代码里写了，也等于没写。
- VS Code 状态栏显示 “UTF-8” ≠ 文件实际是 UTF-8：可能只是以 UTF-8 编码打开一个 GBK 存储的文件
- BOM（
EF BB BF）如果出现在<head>前，会把<meta charset>推到第 4 字节之后，触发 fallback - 写成
<meta charset="utf8">或<meta charset="UTF8">—— 浏览器不识别，只认"UTF-8"（带连字符、大小写敏感）
如何验证 HTML 文件真实编码和 BOM
不能只看编辑器状态栏，要查文件二进制头：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- Linux/macOS：
head -c 4 index.html | xxd→ 输出ef bb bf表示有 BOM；输出3c 68 74 6d（即<htm）表示无 BOM - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3→ 若结果是239 187 191，就是 BOM - VS Code：用
Ctrl+Shift+P→ “Reopen with Encoding” 尝试 GBK/ISO-8859-1，若中文突然可读，说明当前是错编码打开；确认后选 “Save with Encoding” → “UTF-8”（**不要选 “UTF-8 with BOM”**）
HTTP 响应头与 <meta> 的优先级关系
通过 http:// 或 https:// 访问时，HTTP 响应头中的 Content-Type: text/html; charset=xxx 优先级高于 <meta charset>。但 file:// 协议下 HTTP 头完全不存在，此时只靠 <meta>。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置必须写
charset utf-8;（小写，分号结尾），不是charset=UTF-8，也不是add_header Content-Type ...（那会重复 header，可能被浏览器忽略） - Express.js 中
res.sendFile()默认不设 charset，必须在调用前加res.set("Content-Type", "text/html; charset=utf-8") - Chrome DevTools → Network → HTML 请求 → Headers → Response Headers → 查看
Content-Type是否含charset=utf-8；若显示charset=gbk或根本没有 charset，<meta>就会被覆盖
最易被忽略的一点：外部 CSS/JS 文件也必须是 UTF-8 编码，且响应头或 <link>/<script> 标签中不带错误 charset 声明。否则一个 fetch() 回来的 JSON 里中文乱码，跟 HTML 本身无关，但排查路径常被误判。
