基本可断定是编码链路错配而非文字损坏；需验证文件真实编码、确保<meta charset="UTF-8">严格置于<head>开头且无BOM干扰，并确认HTTP响应头charset与之统一。
HTML 文件里中文显示为“ä¸æ–‡”“????”或“”，基本可以断定是编码链路中某处错配，而不是文字本身损坏。只要原始字节还在，90% 以上能恢复；如果已变成问号或菱形符号（），说明解码时已被替换，此时应优先找回原始文件。
确认 HTML 文件实际保存的编码格式
别信编辑器右下角显示的“UTF-8”——它只是当前打开方式，不是文件真实编码。必须验证磁盘上存的是什么：
- VS Code：右下角点击编码名 → 选
Save with Encoding→ 试存为UTF-8、UTF-8 with BOM、GBK各一次，每次保存后关闭再重开看效果 - Linux/macOS：运行
file -i index.html或head -c 4 index.html | xxd，若输出ef bb bf表示有 BOM；若显示charset=iso-8859-1或charset=us-ascii，大概率是 Windows 记事本用 ANSI（即 GBK）保存的 - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，同样看是否输出239 187 191（即 EF BB BF）
<meta charset> 标签位置和写法必须严格正确
这个标签不是“写了就行”，它生效有硬性限制：
- 必须放在
<head>开始之后、<title>之前，且不能有任何字符（包括空格、换行、注释、BOM）在它前面 - 只认
<meta charset="UTF-8">这种写法：utf8、UTF8、utf-8都无效；<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">是 HTML4 兼容写法，但 HTML5 不推荐 - 浏览器只扫描前 1024 字节找这个标签，所以
<meta charset>一定要靠前；如果<head>前有注释或空行，就可能错过 - 若文件是
UTF-8 with BOM，BOM 会占据前 3 字节，此时<meta charset>必须紧跟在 BOM 后面，否则依然失效
HTTP 响应头中的 Content-Type 会覆盖 <meta>
当 HTML 通过 http:// 或 https:// 加载时，服务器返回的 HTTP 头具有更高优先级：
立即学习“前端免费学习笔记（深入）”；
- F12 打开 Network 面板 → 刷新页面 → 点击 HTML 请求 → 查看
Response Headers中的Content-Type字段 - 如果值是
text/html; charset=gbk，哪怕你写了<meta charset="UTF-8">，浏览器也会按 GBK 解析 - Nginx 需配置
charset utf-8;（在http或server块）；Apache 要加AddDefaultCharset UTF-8；Node.js/Express 必须在res.send()前调用res.set("Content-Type", "text/html; charset=utf-8") - 本地双击打开（
file://协议）时没有 HTTP 头，此时才完全依赖<meta charset>和文件自身编码
避免 BOM 引发的连锁失效
Windows 下 VS Code 默认保存带 BOM 的 UTF-8，而 BOM 与 <meta charset> 冲突是高频坑点：
- BOM 存在时，若
<meta charset>没紧贴在 BOM 后（比如中间有空行），浏览器可能跳过该标签，回落到系统默认编码（Windows 是 GBK） - 用
xxd或 PowerShell 确认 BOM 存在后，可手动删掉：在 VS Code 中右下角点编码 →Reopen with Encoding→ 选UTF-8（不带 BOM）→ 保存；或用命令行sed -i '1s/^\xEF\xBB\xBF//' index.html - 更稳妥的做法是统一禁用 BOM：VS Code 设置中搜
files.autoGuessEncoding关掉，files.encoding设为utf8，并勾选files.enableTrash防误覆盖
最易被忽略的一点：乱码常是“多层叠加”导致的——比如文件存为 GBK，<meta charset> 写了 UTF-8，服务器又返回 charset=iso-8859-1。修复时必须一层层剥离验证，不能只改一个地方就以为解决了。
