浏览器实际编码以response headers中content-type的charset为准，如text/html; charset=gbk则按gbk解码；html真实编码需通过file -i、xxd或powershell查原始字节，bom和服务器响应头优先级高于。
怎么看浏览器实际用了什么编码
打开开发者工具（F12），切到 Network 面板，刷新页面，点击 HTML 请求，看 Response Headers 里的 Content-Type 字段。如果写着 text/html; charset=gbk，浏览器就按 GBK 解码，哪怕你写了 <meta charset="UTF-8"> 也没用。无痕窗口里也得这么查——普通窗口可能缓存了旧响应头，误导判断。
怎么确认HTML文件本身是UTF-8还是GBK
别只看编辑器右下角显示的“UTF-8”，那是它当前打开方式，不是文件真实字节。真正要看的是原始字节：
- Linux/macOS：运行
file -i index.html，看输出的charset=值；再用head -c 3 index.html | xxd看开头是不是ef bb bf（UTF-8 BOM） - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191就有 BOM - VS Code：右下角点击编码名称 → 选
Reopen with Encoding，挨个试UTF-8、GBK、ISO-8859-1，哪个能正常显示中文，哪个就是真实编码
<meta charset> 为什么经常失效
它只在 HTTP 响应头没声明 charset 时才起作用，而且必须出现在前 1024 字节内、 开始之后、且前面不能有 BOM 或空行/注释。常见失效场景：
-
<meta charset="utf8">—— 缺少短横线，不是标准写法，部分浏览器忽略 - 文件以 UTF-8 BOM（
ef bb bf）开头，但<meta charset="UTF-8">写在 BOM 后面第 2 行，解析器可能跳过 - 服务器返回
Content-Type: text/html; charset=gbk，浏览器直接按 GBK 解，根本不读<meta> -
<meta>被塞进<script></script>或注释后面，超出了前 1024 字节范围
服务端配置是否覆盖了HTML声明
Apache、Nginx、Tomcat 这些服务器如果在响应头里硬写了 charset，前端 <meta> 就完全作废。检查方法：
- Apache：
.htaccess里有没有AddDefaultCharset；httpd.conf是否全局设了 - Nginx：
nginx.conf里有没有charset utf-8;或add_header Content-Type "text/html; charset=utf-8"; - Tomcat：
server.xml的Connector标签是否加了URIEncoding="UTF-8"和useBodyEncodingForURI="true"
BOM 是最隐蔽的干扰项：它会让编辑器误判编码，又让 <meta> 失效，还可能触发服务器 fallback 到 GBK。只要没特殊兼容需求，保存 HTML 时务必选 “UTF-8 without BOM”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
