HTML中文乱码源于文件编码、HTTP响应头、<meta charset>三者不一致；需统一为UTF-8（无BOM），确保<meta>在前1024字节且位置正确，HTTP响应头优先级高于<meta>，并用xxd或PowerShell验证实际字节。
HTML中文乱码不是单一环节出错，而是文件编码、HTTP响应头、<meta charset> 三者不一致导致的连锁失效。只要其中任一环节错配（比如文件存为 GBK，但 <meta charset="UTF-8"> 又写在 BOM 后面），浏览器就会 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 常是 ISO-8859-1），结果就是“ä¸æ–‡”或“”。
确认 HTML 文件实际编码格式
别信编辑器右下角显示的“UTF-8”——它可能只是当前打开方式，不是文件真实字节。VS Code 显示 “GBK”，很可能文件就是 GBK 编码；显示 “UTF-8 with BOM”，则开头三个字节应是 EF BB BF。
- Linux/macOS：运行
file -i index.html或head -c 4 index.html | xxd，看输出是否含utf-8或ef bb bf - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，检查前 3 字节是否为239 187 191 - 若显示
charset=iso-8859-1或charset=us-ascii，基本可断定文件是 GBK/GB2312 但被误读了
检查 <meta charset> 是否生效
这个标签只在前 1024 字节内有效，且不能被任何字符干扰——BOM、空行、注释、甚至 <script> 标签提前出现，都会让它失效。
-
<meta charset="utf8">错：必须是"UTF-8"（大小写敏感，带连字符） - 位置错误：必须紧贴
<head>开始，前面不能有空格、<!-- comment -->、BOM 或换行 - 重复冲突：如果 HTTP 响应头已含
Content-Type: text/html; charset=gbk，<meta>直接被忽略
验证并统一 HTTP 响应头中的 Content-Type
本地双击打开 file:// 时，浏览器只认 <meta>；但通过 Web 服务器访问（http:// 或 https://）时，响应头优先级高于 <meta>。Nginx、Apache、PHP、Node.js 默认都不发 charset=utf-8，极易踩坑。
立即学习“前端免费学习笔记（深入）”；
- Chrome F12 → Network → 刷新页面 → 点 HTML 请求 → Headers → Response Headers → 查看
Content-Type值 - Nginx：在
location块中加add_header Content-Type "text/html; charset=utf-8";（注意：不是charset utf-8;，后者只影响静态文件，不覆盖响应头） - Express：在
res.send()或res.sendFile()前调用res.set("Content-Type", "text/html; charset=utf-8") - PHP：在任何输出（包括空白、
<?php前空格）之前调用header("Content-Type: text/html; charset=utf-8")
修复文件保存与 BOM 的隐性冲突
VS Code 在 Windows 上默认保存为 UTF-8 with BOM，而 BOM 一旦出现在 <meta charset> 前，就导致该标签被跳过——这是最隐蔽也最常见的失效原因。
- 操作顺序必须是：先用正确编码（如 GBK）重新打开乱码文件 → 全选复制内容 → 新建空白文件 → 切换编码为 UTF-8（不带 BOM）→ 粘贴 → 保存
- 不要直接 “Save with Encoding” → UTF-8 with BOM，这会保留旧 BOM 并叠加新 BOM，更糟
- Sublime Text / Notepad++ 用户：保存时明确勾选 “UTF-8” 而非 “UTF-8 with BOM”
- 验证：保存后再次用
xxd或 PowerShell 检查开头三字节，确保不再是EF BB BF
BOM 和 <meta> 的位置关系、HTTP 响应头与 meta 的优先级博弈、编辑器显示编码与实际字节的错位——这三者交织在一起，才是乱码反复复现的根源。改完一个地方，务必用 F12 Network 面板重新验证响应头和实际字节，而不是仅靠肉眼刷新页面。
