浏览器解析崩溃是因为文件实际为GBK编码却声明UTF-8，导致字节被错误解析而DOM构建失败；真实编码需用file -i、xxd或PowerShell验证，HTTP响应头Content-Type优先级高于meta。
HTML文件实际编码与不一致时为什么崩溃
浏览器解析 HTML 时，<meta charset="UTF-8"> 只是 fallback 提示，真正起效的是文件实际字节流 + HTTP 响应头 Content-Type。如果文件实际是 GBK 编码（比如用记事本另存为“ANSI”），但写了 <meta charset="UTF-8">，浏览器会强行按 UTF-8 解析每个 GBK 字节——一个 GBK 中文占 2 字节，UTF-8 解析器却可能把它当做一个非法的 3 字节序列，直接卡在第一个中文字符处，后续 DOM 构建失败、JS 不执行、样式不加载，看起来像“页面崩溃”。
如何快速验证 HTML 文件的真实编码
别信编辑器右下角显示的“UTF-8”，它只代表当前打开时的解码方式，不是文件真实字节：
- Linux/macOS：
file -i index.html—— 看输出中charset=后面的值；再用head -c 3 index.html | xxd检查开头是否为ef bb bf（BOM） - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3—— 输出若为239 187 191，说明有 BOM - VS Code：右键底部状态栏编码名 → “Reopen with Encoding” → 依次试
GBK、UTF-8、ISO-8859-1，哪个能正确显示中文，哪个就是真实编码
HTTP 响应头 Content-Type 比 <meta> 优先级高
只要服务端返回了 Content-Type: text/html; charset=gbk，哪怕 HTML 里写 <meta charset="UTF-8"> 也完全无效。常见踩坑点：
- Nginx 默认不发 charset，需显式配置
charset utf-8;（注意不是charset gbk;） - Apache 若配置了
AddDefaultCharset GBK，会覆盖所有 HTML 的<meta> - Node.js/Express 中
res.send(html)不带 header，默认是text/html; charset=utf-8，但若用了res.sendFile()或静态托管，可能走默认 mime 类型，不带 charset - PHP 中
header('Content-Type: text/html; charset=gb2312');写在<?php之后、输出之前，但若前面有空格或 BOM，header 会失效，退化为浏览器 fallback
Python 读写 HTML 文件时的编码陷阱
Python 默认用系统 locale 解码文件，Windows 上常是 cp936（GBK），直接 open('page.html').read() 就可能抛 UnicodeDecodeError：
立即学习“前端免费学习笔记（深入）”；
- 读取时必须显式指定 encoding：
open('page.html', encoding='utf-8')或encoding='gbk'，不能依赖默认 - 写入时务必指定 encoding：
open('out.html', 'w', encoding='utf-8')，否则 Python 可能用 locale 编码写入，生成 GBK 字节但没声明 - 用
chardet.detect()自动识别编码风险很高——短文本、纯英文、无中文标签时准确率暴跌，不如人工验证可靠
BOM 是个双刃剑：UTF-8-BOM 能让旧版 IE 正确识别编码，但在 Node.js/PHP 模板渲染中可能被当作非法字符输出，导致 JSON 解析失败或 CSS/JS 加载中断。除非明确兼容 IE，否则保存 HTML 时选 “UTF-8”（无 BOM）更稳妥。
