必须同时满足HTML文件UTF-8无BOM、meta charset在head最前、HTTP响应头charset= UTF-8三条件，缺一中文即乱码；因浏览器仅扫描前1024字节找meta，位置靠后或被注释/BOM遮挡则失效；文件真实编码需用file -i和xxd验证，HTTP头优先级高于meta，调试须三者全查。
必须同时满足三个条件才能让中文正常显示：HTML 文件本身是 UTF-8 编码（无 BOM）、<meta charset="UTF-8"> 出现在 <head> 开头、HTTP 响应头 Content-Type 中的 charset 也设为 UTF-8。缺一不可，浏览器只认这三者一致时的结果。
为什么 <meta charset="UTF-8"> 必须放在 <head> 最前面？
浏览器解析 HTML 时，只扫描前 1024 字节来查找 <meta charset>。如果它被 <title>、注释、<script> 或 BOM 挡在后面，就可能错过——哪怕它存在，也会退回到系统默认编码（比如 Windows 上的 GBK），导致中文变成 。
常见错误现象：
-
<head><title>首页</title><meta charset="UTF-8"></head>→ 失效 -
<head><!-- 注释 --><meta charset="UTF-8"></head>→ 在 IE 中可能失效（BOM 被注释遮挡） -
<head><meta charset="UTF-8"><title>首页</title></head>→ 正确
如何验证文件实际编码是否为 UTF-8（不含 BOM）？
编辑器显示的“UTF-8”不等于文件真实编码。很多编辑器（如 VS Code）新建文件默认 UTF-8，但打开一个旧 GBK 文件后没手动另存为 UTF-8，内容仍按 GBK 存储——此时即使写了 <meta charset="UTF-8">，浏览器也会用 UTF-8 解 GBK 字节，出现 04 类乱码。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
实操建议：
- Linux/macOS 下运行：
file -i your.html，确认输出含charset=utf-8 - 用
xxd -l 3 your.html查看文件头：若显示ef bb bf，说明带 BOM，需去除（VS Code 保存时选 “UTF-8” 而非 “UTF-8 with BOM”） - Notepad++：编码 → 转为 UTF-8（无 BOM）→ 另存为
- Sublime Text：File → Save with Encoding → UTF-8
HTTP 响应头 Content-Type 的优先级高于 meta
当服务器返回的响应头中 Content-Type: text/html; charset=GBK，浏览器会强制用 GBK 解析，无视 <meta charset="UTF-8">。Chrome/Firefox 都会这样，不是 bug，是规范行为。
配置要点：
- Nginx：在
http、server或location块中加charset utf-8; - Apache：在
.htaccess中写AddDefaultCharset UTF-8或Header set Content-Type "text/html; charset=UTF-8" - Node.js/Express：路由中调用
res.setHeader('Content-Type', 'text/html; charset=UTF-8') - 本地直接双击打开（
file://协议）：HTTP 头不存在，此时只依赖meta和文件编码
调试时最该看哪几个地方？
别猜，直接查三项是否全为 UTF-8：
- Network 标签页 → 点开 HTML 请求 → Response Headers → 找
Content-Type字段值 - Elements 标签页 → 展开
<head>→ 确认<meta charset="UTF-8">存在且位置正确 - 控制台执行：
document.characterSet和document.inputEncoding，两个都应返回"UTF-8"
只要其中一项不一致，中文就可能出问题。最容易被忽略的是文件实际编码和 HTTP 响应头的隐式覆盖——它们不写在 HTML 里，却起决定性作用。
