HTML页面乱码主因是HTTP响应头未设charset=utf-8，而非meta写错；浏览器解析顺序为：响应头→前1024字节内meta→系统默认，响应头缺失时即使meta正确也会乱码。
HTML 页面乱码，90% 是因为 HTTP 响应头没设 charset，而不是 meta 写错了。 单独靠 <meta charset="UTF-8"> 在动态页面里基本无效——浏览器在收到第一个字节时就已决定用什么编码解码，此时服务端响应头都还没发完。
HTTP 响应头优先于 meta charset
浏览器解析顺序固定：先看 HTTP Content-Type 响应头 → 扫描 HTML 前 1024 字节找 <meta charset> → 最后 fallback 到系统默认（Windows 是 GBK，Linux/macOS 是 ISO-8859-1）。只要响应头没带 charset=UTF-8，哪怕 meta 写得再标准，中文、emoji、特殊符号都会崩。
- PHP 必须在任何输出前调用
header('Content-Type: text/html; charset=UTF-8');，否则空白或 BOM 都会触发 headers already sent 错误 - Express.js 中
res.set('Content-Type', 'text/html; charset=utf-8')要放在res.send()或res.end()之前，不能写在中间或后面 - Flask 返回 HTML 时别只用
render_template，得显式指定 MIME 类型：return Response(html, mimetype='text/html; charset=utf-8') - Apache 的
AddDefaultCharset UTF-8只对静态 HTML 生效；.php/.py 等脚本必须自己设响应头，.htaccess里的设置不穿透到动态内容
<meta charset="UTF-8"> 的位置和有效性边界
这个标签不是写上就起作用的。它必须是 <head> 内第一个非空格、非注释、非 BOM 的标签，且必须出现在前 1024 字节内。一旦被注释、JS、内联样式或大段空格挤到后面，浏览器直接跳过。
- 错误写法：
<head><!-- 注释 --><script>...</script><meta charset="UTF-8"></head>—— 注释和<script>占位导致扫描失效 - 正确顺序：
<head><meta charset="UTF-8"><title>.../head>，且<meta>前不能有任何字符（包括 UTF-8 BOM） - VS Code 默认保存为 UTF-8 with BOM，这会让
<meta>实际落在第 4 字节之后，直接失效；务必选 “Save with Encoding → UTF-8”（不带 BOM） - 别写
charset="utf8"或charset="UTF_8"—— 只有"UTF-8"（大小写敏感，连短横都不能少）是 HTML5 规范认可的合法值
文件编码、响应头、meta 三者必须一致
三者任意一对不匹配，乱码就会“叠加发生”。比如 PHP 文件本身是 GBK 编码，但响应头设了 charset=UTF-8，浏览器就会用 UTF-8 去解 GBK 字节流，一个中文变成两个问号或方块。
立即学习“前端免费学习笔记（深入）”；
- 验证文件真实编码：Linux/macOS 运行
file -i index.html；PowerShell 用Get-Content index.html -Encoding Byte | Select -First 3看是否为239, 187, 191（UTF-8 BOM） - 验证响应头：Chrome DevTools → Network → 点开 HTML 请求 → Headers → Response Headers → 查看
Content-Type是否含charset=UTF-8 - 验证运行时实际编码：Console 里执行
document.characterSet，返回值必须是UTF-8 - Nginx 配置只需一行：
charset utf-8;（小写，分号不能少），写在server或location块里；不要用add_header Content-Type，那会覆盖原有头
最容易被忽略的是：前端 JS/CSS/JSON 文件也必须是 UTF-8。哪怕 HTML 完全正确，一个 GBK 编码的 app.js 里写了中文字符串，照样报 InvalidCharacterError 或 fetch 解析失败。所有文本资源，统一 UTF-8，一个都不能少。
