彻底解决HTML中文乱码需同步校准文件实际编码、HTTP响应头和浏览器解析顺序三者；仅加<meta charset="UTF-8">无效，它优先级最低且受限于前1024字节与BOM存在与否。
彻底解决 HTML 中文乱码，关键不是加一句 <meta charset="UTF-8"> 就完事——它只是最后一环。真正卡住的，是文件实际编码、HTTP 响应头、浏览器解析顺序三者没对齐。只要其中一环掉链子，<meta charset> 就会被跳过或覆盖。
怎么确认 HTML 文件真实编码（不是编辑器显示的）
VS Code 显示 “UTF-8” 很可能只是它猜的，尤其 Windows 下打开老文件时，默认按 GBK 解码再“强行标成 UTF-8”，内容早已损坏。
- Linux/macOS：用
file -i index.html看输出里的charset=，不是靠编辑器状态栏 - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，如果输出是239 187 191（即十六进制ef bb bf），说明有 BOM；但 BOM 存在 ≠ 编码正确，还得结合file命令判断 - 用十六进制查看器（如
xxd -l 4 index.html）确认开头三字节：无 BOM 应为纯文本字节，有 BOM 则必须和后续内容语义一致（比如 BOM + 后续是 GBK 字节 = 白忙活）
为什么 <meta charset="UTF-8"> 经常失效
浏览器只扫描 HTML 前 1024 字节找 <meta charset>，且优先级低于 HTTP 响应头。一旦前面混入不可见字符（BOM、注释、空格、中文注释、甚至 AI 生成的隐藏 Unicode 控制符），就直接 fallback 到系统默认编码（Windows 是 GBK）。
- 必须放在
<head>开始后**第一个**标签，前面不能有任何字符（包括空格、换行、<!-- -->、BOM） - 写成
<meta charset="utf8">或<meta charset="UTF8">会失效 —— 只认UTF-8（带短横线，大小写不敏感但推荐全大写） -
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">是 HTML4 兼容写法，HTML5 不推荐，且同样受前 1024 字节限制
HTTP 响应头 Content-Type 比 meta 标签更优先
通过 http:// 或 https:// 访问时，服务器返回的 Content-Type 响应头直接决定解码方式。<meta charset> 只有在响应头没声明 charset 时才起作用。
立即学习“前端免费学习笔记（深入）”；
- Nginx：在
server或location块里加charset utf-8;（注意小写，不是UTF-8） - Apache：在站点根目录放
.htaccess，写AddDefaultCharset UTF-8 - Express：在
res.sendFile()或res.send()前调用res.set('Content-Type', 'text/html; charset=utf-8') - PHP：在任何输出前（连空白都不能有）调用
header('Content-Type: text/html; charset=utf-8');
开发环境最容易被忽略的坑
本地双击打开 file:// 协议的 HTML，没有 HTTP 响应头，完全依赖 <meta charset> 和文件编码。此时 VS Code 的“保存编码”选项就是唯一救命稻草。
- VS Code：务必用 **Save with Encoding → UTF-8**（不是 “UTF-8 with BOM”）；若当前显示为 GBK，先选 **Reopen with Encoding → GBK**，再另存为 UTF-8
- Sublime Text / Notepad++：保存时明确选 “UTF-8”，禁用 BOM 选项
- 模板引擎（如 Thymeleaf、EJS）：单独配置其输出编码，例如 Thymeleaf 的
templateResolver.setCharacterEncoding("UTF-8")，否则生成的 HTML 文件本身就不对
最麻烦的不是某一处设错，而是多层叠加：文件存成 GBK、编辑器显示成 UTF-8、HTTP 响应头写成 charset=gbk、meta 标签还漏写了——这种组合会让浏览器在几毫秒内完成三次编码 fallback，最后显示一堆 。排查时得一层层断，别指望改一个地方就全好。
