浏览器实际解析编码以document.characterset返回值为准，优先查response headers中content-type的charset，其次看是否位于最前且无bom，再用file -i验证文件真实编码，三者必须统一。
HTML 编码设置是否生效，不能只看 <meta charset="UTF-8"> 写没写，关键得验证浏览器**实际解析时用的是不是这个编码**。很多乱码问题就卡在这一步——标签写了，但服务器响应头覆盖了它，或文件本身保存编码不匹配。
怎么看浏览器实际用了哪个编码？
打开开发者工具（F12 或右键 → “检查”），切换到 Network 面板 → 刷新页面 → 点击主 HTML 请求（通常是第一个，Name 列显示 index.html 或类似）→ 查看右侧 Headers 标签页 → 在 Response Headers 区域找 Content-Type 字段。
如果看到类似 Content-Type: text/html; charset=utf-8，说明服务器明确声明了 UTF-8；如果只有 text/html 没带 charset，浏览器才会退而求其次，去读 HTML 里的 <meta charset>；如果这里写的是 gbk 或 iso-8859-1，那 <meta> 标签基本被无视。
- 响应头中的
charset优先级 > HTML 中的<meta charset> - 如果响应头没声明，且 HTML 里也没
<meta charset>，浏览器会按历史启发式规则猜测（比如中文环境倾向 GBK），极易出错 -
view-source:页面顶部显示的编码名（如 Chrome 地址栏旁的小图标）是浏览器当前采用的解析编码，不是你写的那个
为什么 <meta charset> 放错位置会失效？
这个标签必须在 内、且**尽可能靠前**，理想位置是 的第一行。如果前面有 <title></title>、<script></script> 或注释，浏览器可能已经按默认编码（如 GBK）解析了一部分字节，再遇到 <meta> 就来不及回退重解了。
- 错误写法：
<title>首页</title> <meta charset="UTF-8">——<title></title>里的中文可能已被错误解码 - 正确写法：
<meta charset="UTF-8"> <title>首页</title> - 注意：不要写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，这是旧写法，兼容性差，且在 HTTP/2 下可能被忽略
怎么确认文件本身保存编码和声明一致？
编辑器里看到的“UTF-8”不等于磁盘上真是 UTF-8。用 VS Code 打开 HTML 文件，右下角会显示当前编码（如 UTF-8 或 GBK）。点击它可重新以某编码打开，或“通过编码重新打开”来验证——如果选 GBK 后中文正常、选 UTF-8 变乱码，说明文件其实是 GBK 编码，但你却声明了 UTF-8。
- Sublime Text / Notepad++ 也提供类似编码检测和转换功能，别依赖“自动识别”
- 保存时务必选“UTF-8 无 BOM”，BOM（
EF BB BF）会导致某些老服务端脚本（如 PHP）在输出前多吐出三个不可见字节，破坏响应头 - Linux/macOS 下可用命令
file -i filename.html查看文件实际编码
真正难排查的，往往是响应头、文件保存编码、HTML 声明三者不统一。单改一个地方常无效，得三处对齐才稳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
