浏览器优先采用HTTP响应头Content-Type中的charset，若缺失或与<meta charset="UTF-8">冲突，则fallback至系统默认编码（Windows为GBK，Linux/macOS常为ISO-8859-1），导致中文显示为问号或方块；需检查Response Headers、文件真实编码、meta标签位置及写法，并确保Web服务器未覆盖charset。
Content-Type 响应头缺失或与 <meta charset="UTF-8"> 冲突时，浏览器会 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 默认可能是 ISO-8859-1），中文立刻变问号或方块。这不是“浏览器坏了”，而是它根本没收到明确指令。
检查 Network 面板里的 Response Headers
打开 Chrome 或 Edge 的 DevTools → Network → 刷新页面 → 点 HTML 文件那一行 → 查看右侧 Headers → Response Headers → 找 Content-Type 字段：
- 如果值是
text/html; charset=gbk或text/html; charset=iso-8859-1，<meta charset="UTF-8">会被直接忽略 - 如果字段完全不存在，服务器没发 charset，浏览器就按自己猜的来（大概率错）
- 如果值是
text/html; charset=utf-8（注意小写utf-8），但页面仍乱码，说明文件本身不是 UTF-8 编码
验证 HTML 文件实际编码（绕过编辑器显示）
VS Code 右下角显示 “UTF-8” 不代表文件真是 UTF-8 —— 它可能只是“用 UTF-8 解释了 GBK 字节”。真实编码得看字节：
- Linux/macOS：
file -i index.html或head -c 4 index.html | xxd，看到ef bb bf表示有 BOM；若显示charset=us-ascii或charset=unknown-8bit，基本是 GBK - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，输出239 187 191即 BOM - Sublime Text：右下角编码名点击 → “Reopen with Encoding” 尝试 GBK/UTF-8/ISO-8859-1，哪个能正常显示中文，就是当前真实编码
确认 <meta charset> 位置和写法
这个标签必须满足三个硬性条件，缺一不可：
立即学习“前端免费学习笔记（深入）”；
- 必须在
<head>内，且是<head>里第一个非空、非注释的标签（前面不能有空格、换行、<!-- comment -->） - 必须写成
<meta charset="UTF-8">或<meta charset="utf-8">（大小写不敏感，但不能写utf8或UTF8） - 不能和
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">并存 —— 后者是 HTML4 兼容写法，现代 HTML5 中二者选一，重复会导致部分旧浏览器解析异常
排查 Web 服务器是否覆盖了 charset
即使 HTML 里写了 <meta charset="UTF-8">，Nginx/Apache/PHP 也可能在 HTTP 响应头里强行指定别的编码：
- Nginx：检查
nginx.conf或 site 配置里有没有charset gbk;或add_header Content-Type "text/html; charset=gbk";—— 这类配置会覆盖 HTML 内声明 - Apache：
.htaccess里若有AddDefaultCharset GBK，也会压倒<meta> - PHP：
header("Content-Type: text/html; charset=gbk");必须改成utf-8，且必须在任何echo、print或空白输出前调用
BOM 是个隐形开关：UTF-8 with BOM 在 Windows 记事本里“看起来正常”，但在 VS Code 里若被误判为 GBK，保存时又选错编码，就会陷入“显示正常 → 实际乱码 → 越改越糟”的循环。真正可靠的判断依据永远是字节，不是编辑器右下角那行字。
