浏览器在收到前1024字节时启动解码，优先级为：HTTP响应头Content-Type→HTML中<meta charset>→系统默认；<meta charset>须置于<head>最前，否则被跳过。
浏览器解析 HTML 字符编码的时机和顺序
浏览器不是等整个 HTML 下载完才开始解析，而是在收到前 1024 字节时就启动解码流程。它会按固定优先级尝试确定字符编码：先查 HTTP 响应头的 Content-Type 字段，再查 HTML 中的 <meta charset>，最后 fallback 到系统默认（Windows 是 GBK，macOS/Linux 是 ISO-8859-1）。这个顺序不可逆，Content-Type 里的 charset 永远比 <meta charset="UTF-8"> 优先。
为什么 <meta charset> 必须放在 <head> 最前面
因为浏览器只扫描前 1024 字节来查找编码声明。一旦遇到注释、空格、BOM 或 <title> 标签挡在前面，就会跳过后面的 <meta charset> —— 它根本不会继续往后读。
-
<head><meta charset="UTF-8"><title>首页</title></head>✅ 正常生效 -
<head><title>首页</title><meta charset="UTF-8"></head>❌ 失效（<title>已占用字节位置） -
<head><!-- 注释 --><meta charset="UTF-8"></head>❌ 失效（注释也算字节） -
<head><meta charset="utf-8"></head>⚠️ 可能警告（HTML5 规范要求写UTF-8，大小写和连字符不能省）
常见乱码现象与对应原因
看到方框、问号、小方块或 Uncaught SyntaxError: Invalid or unexpected token，基本不是字体问题，而是编码链断裂。关键看哪一层没对齐：
- 整页中文全变问号 →
Content-Type响应头缺失或写成charset=GBK，或文件实际是 GBK 却声明 UTF-8 - JS 报错但源码里中文正常 → HTML 文件保存为 UTF-8 with BOM，而某些 WebView 或 CI 工具把 BOM 当作 JS 首字符解析
- 刷新后偶尔正常 → 服务端缓存了不同编码版本的响应，或 CDN 返回了未带
charset的旧头 - 只有表格内文字乱码 → 不是
<table>特殊，只是你恰好把中文写在了<meta charset>生效范围之外的位置
如何验证当前生效的编码
别猜，直接看运行时状态：
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Network → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type值 - 在 Console 执行
document.characterSet，返回值必须是"UTF-8"（注意引号和大小写） - 用命令行检查文件真实编码：
file -i index.html（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell），确认无 BOM（即前 3 字节不是239, 187, 191）
最易被忽略的是：本地用 file:// 打开时，HTTP 响应头不存在，此时 <meta charset> 是唯一依据，但它的生效前提是文件本身真为 UTF-8 编码且无干扰字符——编辑器右下角显示的“UTF-8”不等于文件实际编码。
