HTML中文乱码本质是浏览器编码识别错误，非文件损坏；90%以上可恢复，关键在确认文件真实编码而非编辑器右下角显示——需用head -c 4 | xxd（Linux/macOS）或Get-Content -Encoding Byte | Select -First 3（PowerShell）验证BOM及实际字节。
HTML 中文乱码不是“文件坏了”，而是浏览器用错了编码方式读取字节——只要原始字节没被覆盖（比如没变成问号或），90%以上都能恢复。
确认文件真实编码，别信编辑器右下角显示
VS Code、Sublime 等编辑器右下角标着 “UTF-8” 或 “GBK”，只是它“猜”的结果，不一定对。真正决定内容的是文件开头的字节序列。
- Linux/macOS 下检查 BOM：
head -c 4 index.html | xxd，输出ef bb bf表示有 UTF-8 BOM；无则可能为纯 UTF-8 或 GBK - Windows PowerShell 检查：
Get-Content index.html -Encoding Byte | Select -First 3，同样看是否为239 187 191 - 若显示为
00 00或乱码开头，可能是 UTF-16；若开头是中文“但显示为“鐢ㄦ埛”类字符，大概率是 UTF-8 被当成了 GBK 读取 - 别直接改后缀或盲目重存：用“Save with Encoding”选错格式（比如把 GBK 文件强行存成 UTF-8 without BOM）会永久损坏
<meta charset> 失效的常见原因和修复位置
<meta charset="UTF-8"> 只在 开头 1024 字节内有效，且前面不能有任何不可见字符。
- 必须紧贴
标签之后，前面不能有空格、换行、BOM、HTML 注释（<!-- -->）或任何其他字符 - 写成
<meta charset="utf8">或<meta charset="UTF8">会失效——只接受UTF-8（带连字符、大写 U、T、F） - 不要和
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">并存，HTML5 只认前者，后者反而可能干扰 - 如果文件是通过
file://协议本地打开（没走 HTTP），<meta charset>是唯一生效方式；此时服务器响应头完全不起作用
HTTP 响应头与 <meta> 冲突时谁赢？
当页面通过 HTTP（http:// 或 https://）加载时，Content-Type 响应头优先级高于 <meta charset> ——哪怕 <meta> 写对了，响应头错也会乱码。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置中，
charset utf-8;是全局设置，但若某 location 里写了add_header Content-Type "text/html; charset=gbk";，就会压倒 HTML 里的<meta> - Node.js/Express 中，
res.set("Content-Type", "text/html; charset=utf-8")必须在res.send()之前调用；放在后面等于没设 - PHP 中，
header("Content-Type: text/html; charset=utf-8")必须在任何输出（包括空白、<?php前空行、BOM）之前执行，否则报“headers already sent” - F12 打开 Network 面板，点击 HTML 请求 → Headers → Response Headers，直接看
Content-Type值，这是最真实依据
乱码已变问号或，还能救吗？
一旦复制出来是“?”或“”，说明原始字节已被替换，无法从当前文本反推——这不是编码问题，是数据已损毁。
- “?” 通常来自数据库字段定义为
CHARSET=latin1却存了 UTF-8 字节，再 SELECT 时被转成 ? - “”（U+FFFD 替代字符）表示解码失败，原始字节流中存在非法 UTF-8 序列，且已被丢弃或替换
- 此时唯一可靠来源是：未保存前的编辑器缓存、Git 历史版本、备份文件、上游接口原始响应（curl 抓包）、或数据库原始 binlog
- 不要用“编码转换工具”反复尝试：每转换一次都可能叠加新错误，越转越糟
