答案是先看源码里中文是否为“是个”类误读（说明UTF-8字节被错解），还是“?”类原始破坏（改meta无效）；再查响应头Content-Type是否为text/html; charset=utf-8；最后验证HTML文件是否真为UTF-8无BOM且位于head开头1024字节内。
先看源码里中文是不是“真乱码”——如果 Ctrl+U 看到的是“是个”这类，说明浏览器误读了 UTF-8 字节；如果看到的是“?”或空白，说明原始字节早就被破坏了，改 meta 没用。
检查 HTTP 响应头里的 Content-Type 是否带 charset=utf-8
打开 DevTools → Network → 刷新页面 → 找到 HTML 请求 → 点击 → 查 Response Headers。关键看 Content-Type 的值：
- ✅ 正确：
text/html; charset=utf-8（注意是utf-8，不是UTF8、utf8或UTF-8大写连字符） - ❌ 错误：
text/html; charset=gbk（与<meta charset="UTF-8">冲突）、text/html（缺 charset 参数）、text/html; charset=us-ascii（不支持中文） - Nginx 要在
http/server/location块里加charset utf-8;；Apache 要确认AddDefaultCharset UTF-8没被覆盖；Node.js/Express 必须在res.send()前调res.set("Content-Type", "text/html; charset=utf-8")
验证 HTML 文件本身是否真为 UTF-8 编码（且无 BOM）
<meta charset="UTF-8"> 只在前 1024 字节内生效，且必须出现在 开始后、任何非 ASCII 字符（包括 BOM、注释、空行）之前。常见坑：
- 用记事本保存过 HTML 文件 → 极大概率插入了 UTF-8 BOM（
EF BB BF），浏览器会跳过 meta 标签，按响应头或默认编码解析 - VS Code / Sublime / Notepad++ 打开文件后，右下角显示的编码名 ≠ 实际保存编码；要点击它 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - Git 提交后乱码？检查
.gitattributes是否有* text=auto eol=lf，避免 Windows 换行符 + BOM 混入
区分静态内容和动态内容的乱码来源
如果只有部分字段（如用户昵称、接口返回文案）乱码，问题不在 HTML 主体，而在数据链路某环：
立即学习“前端免费学习笔记（深入）”；
- 抓取对应 API 请求 → 看响应头
Content-Type：如果是application/json; charset=ISO-8859-1，哪怕 JSON 里是 UTF-8 字节，浏览器也会按 ISO 解析 → 后端必须设为charset=utf-8 - 数据库连接未设 charset：PHP MySQLi 要调
$conn->set_charset("utf8mb4")（注意是utf8mb4，不是utf8）；Python MySQLdb 要传charset='utf8mb4' - 服务间调用（如 Node.js 请求 Python 服务）：检查对方响应头、实际字节流（用
xxd -c 16或在线 hex 工具看前几十字节），别只信文档写的“返回 UTF-8”
真正容易被忽略的点：多语言页面常混用外部资源——CSS 文件、JS 文件、字体文件、SVG 图标。只要其中任一文件保存为 GBK 或含 BOM，就可能污染整个页面的编码推断逻辑。调试时不要只盯着 HTML，用 Network 面板逐个检查所有 .css、.js、.svg 请求的响应头和实际字节。
