浏览器实际解析编码以http响应头content-type中的charset为准，优先级高于meta标签；document.characterset显示运行时真实编码；bom会破坏meta标签生效，需确保文件utf-8无bom、meta为head内首节点且未被响应头覆盖。
直接看浏览器实际用的编码，不是看代码里写了什么。哪怕 <meta charset="UTF-8"> 写得再标准，只要浏览器没按它解析，中文照样乱码。
查 Network 面板里的 Response Headers
这是最权威的判断依据：HTTP 响应头里的 Content-Type 优先级高于 HTML 中任何 <meta> 标签。
- 打开 DevTools → Network → 刷新页面 → 找到主 HTML 文件（通常是
index.html或根路径请求） - 点开它 → 查看
Response Headers→ 找Content-Type字段 - 如果值是
text/html; charset=UTF-8，说明服务器已明确声明，<meta charset>不会起作用（但也不冲突） - 如果值是
text/html（没带charset），或charset=gbk、charset=iso-8859-1，那浏览器就根本不会读你的<meta>，乱码风险极高
看 document.characterSet 或 document.inputEncoding
这两个 JS 属性反映浏览器最终采用的编码，是运行时真实值。
- 在控制台执行
document.characterSet—— 返回当前文档解析所用编码，比如"UTF-8"或"GBK" - 执行
document.inputEncoding—— 含义类似，部分浏览器仍支持，可作交叉验证 - 如果返回
"ISO-8859-1"或"windows-1252"，基本可以断定：HTML 文件本身不是 UTF-8、BOM 被挡、或<meta>位置错（比如前面有空行/注释/BOM）
用命令行快速验 BOM 和文件编码
BOM 是隐形杀手，常被编辑器静默插入，导致 <meta charset> 失效。
- Linux/macOS：
head -c 4 index.html | xxd，输出含ef bb bf就有 BOM - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191就是 BOM - 确认文件真实编码（非编辑器显示）：
file -i index.html（Linux/macOS）或iconv -l | grep -i utf辅助判断 - 有 BOM 且
<meta charset>在它后面？立刻删掉——VS Code 可用 “Save with Encoding → UTF-8”（不带 BOM）重存；或用sed -i '1s/^\xEF\xBB\xBF//' index.html
真正生效的链条只有三环咬死：文件保存为 UTF-8（无 BOM）、<meta charset="UTF-8"> 是 中第一个非空白/非注释节点、HTTP 响应头未强制覆盖 charset。漏一环， 就随时可能出现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
