HTML中文乱码本质是浏览器按HTTP响应头＞<meta charset>＞系统默认编码（如GBK）逐层fallback，任一环未统一UTF-8即可能乱码；需严控BOM、<meta>位置、大小写、服务器响应头及CSS/JS等外部资源编码一致性。
HTML 中文乱码不是“写对了 meta 就完事”，而是浏览器按优先级逐层 fallback 的结果：HTTP 响应头 > <meta charset> > 系统默认编码（如 Windows 的 GBK）。只要其中任一环没对齐 UTF-8，就可能在某台设备、某个浏览器、某种访问方式（比如 file://）下出乱码。
为什么 <meta charset="UTF-8"> 写对了还是乱码
常见错误现象是：VS Code 显示文件编码为 “UTF-8”，但保存时实际用了无 BOM 的 UTF-8；而 Chrome 在 file:// 协议下不读 <meta>，直接 fallback 到 Windows 默认的 GBK，导致中文变成一堆问号或方块。
-
<meta charset="UTF-8">必须出现在<head>的最开头 —— 前面不能有空格、注释、BOM 或任何不可见字符 - 如果文件开头有 BOM（
EF BB BF），但<meta>写在 BOM 后面，某些旧版浏览器会忽略它 -
<meta charset="utf8">或<meta charset="UTF8">是无效写法，必须是"UTF-8"（带连字符） - 用
file://打开时，HTTP 响应头不存在，<meta>是唯一依据，此时 BOM 缺失 + 位置偏移 = 必乱码
如何验证 HTML 文件真正是 UTF-8 with BOM
别信编辑器右下角显示的“UTF-8”，要查真实字节。VS Code 默认 Windows 下保存为 UTF-8 with BOM，但如果你手动改过设置或用其他编辑器（如 Sublime Text 默认无 BOM），就容易翻车。
- Linux/macOS：运行
head -c 4 index.html | xxd，输出含ef bb bf才是带 BOM 的 UTF-8 - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，前三字节应为239, 187, 191 - Notepad++：菜单栏“编码 → 转为 UTF-8-BOM 格式”，再保存
- VS Code：点击右下角编码名称 → “Save with Encoding” → 选
UTF-8 with BOM（不是“UTF-8”）
HTTP 响应头和服务器配置必须同步
哪怕 HTML 文件和 <meta> 都完美，Nginx/Apache/Express 返回的响应头是 Content-Type: text/html; charset=iso-8859-1，浏览器照样无视 <meta> —— 因为响应头优先级更高。
立即学习“前端免费学习笔记（深入）”；
- Nginx：
charset utf-8;放在http或server块里（全局生效），比add_header Content-Type "text/html; charset=utf-8"更可靠 - Apache：
AddDefaultCharset UTF-8写进.htaccess或虚拟主机配置 - Express：
res.set("Content-Type", "text/html; charset=utf-8")必须在res.send()或res.sendFile()之前调用 - PHP：
header("Content-Type: text/html; charset=utf-8");前不能有任何输出（包括 BOM、空行、echo）
外部资源（CSS/JS）也得统一 UTF-8
一个 style.css 里写了 content: "按钮";，但该 CSS 文件本身是 GBK 编码，Chrome 就会把“按钮”解析成乱码，且不会报错。
- CSS/JS 文件同样需保存为 UTF-8 with BOM，并在
<link>或<script>标签中确保路径正确 - 避免在 CSS 中用
@import引入非 UTF-8 的样式表 - 动态插入的 JS 字符串（如
document.title = "首页"）若来自后端接口，接口返回头也得是charset=utf-8 - 字体缺失会导致“□”或空白，但那是渲染问题，不是编码问题；先排除编码再查字体
最容易被忽略的是：BOM 和 <meta> 的位置冲突、file:// 协议下完全依赖文件编码、以及 CSS/JS 这些“配角”文件的编码独立性。三者任一掉链子，乱码就会在某个看似随机的场景里冒出来。
