直接查看浏览器是否 fallback 到 GBK 或 ISO-8859-1：F12 打开开发者工具 → Network → 刷新页面 → 点击主 HTML 请求 → 查 Response Headers 里的 Content-Type；若值为 text/html; charset=gbk 或无 charset 子句，且 document.characterSet 返回 "GBK" 或 "ISO-8859-1"，则 <meta charset="UTF-8"> 已失效。
怎么快速确认是不是失效了
直接看浏览器是否 fallback 到 GBK 或 ISO-8859-1：F12 打开开发者工具 → Network → 刷新页面 → 点击主 HTML 请求 → 查 Response Headers 里的 Content-Type。如果值是 text/html; charset=gbk 或压根没 charset 子句，那 <meta charset="UTF-8"> 就只是备选，大概率已失效。
更直接的线索是 DOM 中文显示为方块、问号或乱码字符串（如 “”、“é”），且 document.characterSet 在控制台输出 "GBK" 或 "ISO-8859-1" —— 这说明浏览器根本没按 UTF-8 解码。
为什么<meta charset="UTF-8">写了也白写
它只在前 1024 字节内生效，且必须是 <head> 内第一个非空白、非注释的标签。常见失效原因：
-
<head>前有 BOM（ef bb bf）—— VS Code 默认 Windows 下保存为 UTF-8 with BOM 就会埋雷 -
<head>开头有空格、换行、HTML 注释（<!-- ... -->）或全角空格（U+3000） -
<meta charset="UTF-8">被写在<title>或<script>后面，超出了扫描范围 - 用了非标准写法：
<meta charset="utf8">、<meta charset="UTF8">、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
如何验证文件实际编码和 BOM 状态
别信编辑器右下角的状态栏，要查真实字节：
立即学习“前端免费学习笔记（深入）”；
- Linux/macOS：
file -i index.html（看charset=值） +xxd -l 4 index.html（看开头是否ef bb bf） - 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，哪个能正常显示中文，就说明当前文件是那种编码；确认后点 “Save with Encoding” → 严格选
UTF-8（不是UTF-8 with BOM）
HTTP 响应头比<meta>优先级高，怎么查它有没有覆盖
本地双击打开 file:// 页面时，没有 HTTP 头，全靠 <meta charset="UTF-8">；但只要走 Web 服务器（Nginx/Apache/Express），响应头里的 Content-Type 就具最高决定权。
常见陷阱：
- Nginx 默认不发
charset，需手动加charset utf-8;（注意是小写，不能写charset=UTF-8） - Apache 的
AddDefaultCharset若设成GBK，会直接压过 meta 标签 - Express 中
res.sendFile()不自动带 charset，必须显式调用res.set("Content-Type", "text/html; charset=utf-8") - PHP 的
header("Content-Type: text/html; charset=utf-8")必须在任何输出（包括 BOM、空格、echo）之前调用
BOM 和响应头冲突是高频盲区：哪怕文件是纯 UTF-8，只要服务器头里写了 charset=gbk，浏览器就照错解。查完 meta，一定得盯住 Network 面板里的响应头。
