<meta charset="UTF-8">必须位于<head>最开头且前面无任何字符（含BOM、空格、注释、<script>），否则浏览器仅扫描前1024字节，遇干扰即跳过并fallback至系统默认编码（如Windows的GBK），导致中文乱码。
meta charset="UTF-8" 必须存在、必须在 <head> 开头、必须写对大小写和连字符，否则浏览器大概率 fallback 到系统默认编码（Windows 下是 GBK），直接显示 。
为什么 meta charset="UTF-8" 有时完全不生效
根本原因不是“写了没用”，而是浏览器压根没读到它——HTML 解析器只扫描前 1024 字节找 meta charset，一旦开头有 BOM、空行、注释或 <script>，它就跳过，直接退回到系统编码。
- BOM（
EF BB BF）会占掉开头 3 字节，把<meta推到第 4 字节之后，但某些旧解析器仍可能误判 -
<head>前写了<!-- 注释 -->或空格/换行，也会让meta超出扫描窗口 - VS Code 默认保存为 “UTF-8 with BOM” 时，
meta实际位置 > 3 字节，极易失效 - 写成
charset="utf8"或charset="UTF8"—— 只有"UTF-8"是标准值，其他均被忽略
如何验证 HTML 文件真实编码与 BOM 状态
不能只看编辑器右下角显示，得查文件实际字节：
- Linux/macOS：
xxd -l 4 index.html，输出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：用 “Reopen with Encoding” 强制以 GBK 打开，如果中文变乱码，说明文件其实是 UTF-8；再用 “Save with Encoding” → 选
UTF-8（**不勾选 “with BOM”**）
HTTP 响应头比 meta 更优先，但 file:// 下完全无效
本地双击打开 HTML（file:// 协议）时，HTTP 头不存在，meta 是唯一依据；一旦走 HTTP（localhost、Nginx、Express），Content-Type: text/html; charset=utf-8 会覆盖 meta，且不校验其位置。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置必须是
charset utf-8;（小写，无等号，分号结尾），写成charset=UTF-8或charset "utf-8"会静默失败 - Express 中
res.sendFile()不自动设 charset，必须手动加：res.set('Content-Type', 'text/html; charset=utf-8') - Apache 的
AddDefaultCharset UTF-8有效，但若响应头里已有Content-Type，它会被忽略
外链 JS/CSS 和 AJAX 请求也得统一 UTF-8
页面本身编码正确，但 <script src="app.js"> 或 fetch() 加载的资源如果存为 GBK，照样乱码；AJAX POST 提交表单时，若没声明 accept-charset="UTF-8"，IE/Edge 可能用系统编码发数据。
-
<script>标签可加charset="UTF-8"属性（虽非必需，但明确更稳） - 表单提交加
accept-charset="UTF-8"，避免老浏览器用 GBK 编码发送中文 - Fetch 请求发中文，确保
headers: { 'Content-Type': 'application/json; charset=utf-8' }，后端也要按此解码
真正卡住人的从来不是“要不要加 meta charset”，而是 BOM 位置、编辑器保存行为、HTTP 头覆盖逻辑这三者叠加后的隐性失效——哪怕只错一个字节或一个空格，UTF-8 就形同虚设。
