浏览器在收到前1024字节时启动解码，优先级为：http响应头content-type→html中→系统默认；须置于最前，否则被跳过。

浏览器解析 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> 必须放在 最前面

因为浏览器只扫描前 1024 字节来查找编码声明。一旦遇到注释、空格、BOM 或 <title></title> 标签挡在前面，就会跳过后面的 <meta charset> —— 它根本不会继续往后读。

• <meta charset="UTF-8"> <title>首页</title> ✅ 正常生效
• <title>首页</title> <meta charset="UTF-8"> ❌ 失效（<title></title> 已占用字节位置）
• <!-- 注释 --><meta charset="UTF-8"> ❌ 失效（注释也算字节）
• <meta charset="utf-8"> ⚠️ 可能警告（HTML5 规范要求写 UTF-8，大小写和连字符不能省）

常见乱码现象与对应原因

看到方框、问号、小方块或 Uncaught SyntaxError: Invalid or unexpected token，基本不是字体问题，而是编码链断裂。关键看哪一层没对齐：

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• 整页中文全变问号 → Content-Type 响应头缺失或写成 charset=GBK，或文件实际是 GBK 却声明 UTF-8
• JS 报错但源码里中文正常 → HTML 文件保存为 UTF-8 with BOM，而某些 WebView 或 CI 工具把 BOM 当作 JS 首字符解析
• 刷新后偶尔正常 → 服务端缓存了不同编码版本的响应，或 CDN 返回了未带 charset 的旧头
• 只有表格内文字乱码 → 不是 <table> 特殊，只是你恰好把中文写在了 <code><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”不等于文件实际编码。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！