HTML乱码根源在于<meta charset>声明与文件实际编码不一致，必须严格匹配；还需确保HTTP响应头、编辑器保存编码、Git及CDN等全链路统一为UTF-8。
HTML 编码本身不解决乱码，但它是乱码问题的起点——如果 <meta charset> 声明和实际文件保存编码不一致，浏览器就大概率会显示乱码。
为什么加了 <meta charset="UTF-8"> 还是乱码
常见现象：HTML 文件里写了 <meta charset="UTF-8">，但中文仍显示为方块、问号或 Mojibake（如“æ们”）。
- 文件实际是 GBK 或 GB2312 编码保存的，而
<meta>却声明 UTF-8，浏览器按 UTF-8 解码就会错位 -
<meta charset>必须放在<head>最前面（最好在<title>之前），否则部分浏览器可能忽略 - 服务器返回的 HTTP
Content-Type响应头（如text/html; charset=GBK）会覆盖 HTML 中的<meta>，优先级更高
如何确认当前 HTML 文件的真实编码
不能只看编辑器右下角显示，要验证实际字节流。推荐方法：
- 用 VS Code 打开文件 → 右下角点击编码名称（如 “UTF-8”）→ 选择 “Reopen with Encoding” → 依次试
UTF-8、GBK、ISO-8859-1，看中文是否正常显示 - 命令行查编码（Linux/macOS）：
file -i your.html或enca -L zh your.html - Sublime Text：菜单栏
File → Reopen with Encoding，逐个尝试
<meta charset> 和文件编码必须严格匹配
匹配错误是绝大多数前端乱码的根源。不是“尽量一致”，而是“必须一致”。
立即学习“前端免费学习笔记（深入）”；
- 若用记事本保存为“ANSI”，在中国大陆环境通常就是 GBK → 此时
<meta charset>必须写GBK（或Windows-1252不适用中文） - VS Code 默认保存为 UTF-8 无 BOM →
<meta charset="UTF-8">正确；若手动选了 “UTF-8 with BOM”，多数情况也能兼容，但不推荐 - 服务端输出 HTML 时，PHP 要确保
header('Content-Type: text/html; charset=utf-8');与文件编码、<meta>三者统一
常见组合示例（可直接对照排查）
以下是最常踩坑的几组真实场景：
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <!-- ✅ 声明 UTF-8 --> <title>你好世界</title> </head> <body></body> </html>
→ 对应文件必须用 UTF-8（无 BOM）保存，且服务器不能返回 charset=gbk 头。
<meta charset="GBK">
→ 仅限老旧系统或需兼容 IE6–8 的内网页面；现代项目强烈避免，因为 UTF-8 是 Web 标准，GBK 无法表示 emoji、生僻汉字、多语言混合文本。
真正难的不是写对那一行 <meta>，而是整个工具链（编辑器保存、Git 提交、HTTP 响应、CDN 缓存）都保持编码上下文一致。漏掉任意一环，乱码就会回来。
