HTML中文乱码是编码链任一环节不匹配所致，包括文件保存、meta声明、HTTP响应头、编辑器设置及BOM存在与否；浏览器仅扫描head前1024字节内的meta charset，BOM、空行或注释会导致其被忽略；HTTP响应头Content-Type优先级最高，可覆盖meta声明；编辑器显示编码≠文件真实编码，需正确转码；JS/CSS文件编码独立于HTML，也须UTF-8无BOM。
HTML中文乱码不是单一环节出错，而是编码链上任一环节断裂都会导致——文件保存、meta声明、HTTP响应头、编辑器设置、甚至BOM存在与否，只要有一个不匹配，汉字就变问号或方块。
为什么 <meta charset="UTF-8"> 放在 <head> 里还是乱码
浏览器只扫描 <head> 开头约 1024 字节内的 <meta charset>，一旦前面有 BOM（EF BB BF）、空行、注释、或错误的 UTF-8 with BOM 文件被当 GBK 解析，就会跳过该标签。VS Code 显示“UTF-8”，实际可能是“UTF-8 with BOM”；Notepad++ 里显示“ANSI”，往往就是 GBK。常见现象包括：
- 本地双击打开正常，但用
file://协议访问就乱码（因无 HTTP 头，全靠 meta 和 BOM） - Chrome 开发者工具 Network 标签页中，Response Headers 的
Content-Type显示text/html; charset=iso-8859-1，覆盖了 meta 声明 -
<meta charset="UTF-8">写在<title>后面，或前面有<!-- 注释 -->或空格，导致被忽略
验证方式：Linux/macOS 下运行 file -i index.html；Windows PowerShell 中运行 Get-Content index.html -Encoding Byte | Select -First 3，若输出 ef bb bf，说明含 BOM。
服务器返回的 Content-Type 头比 <meta> 更优先
HTTP 响应头中的 Content-Type: text/html; charset=xxx 具有最高解析权，会直接覆盖 HTML 内的 <meta charset>。Nginx、Apache、Express 等都可能默认发错 charset：
立即学习“前端免费学习笔记（深入）”；
- Nginx：配置中漏掉
charset utf-8;，或写了add_header Content-Type "text/html; charset=gbk";（重复设置会导致冲突） - Apache：.htaccess 中未加
AddDefaultCharset UTF-8，或被高优先级配置覆盖 - Express：用
res.sendFile()时未手动设头，Node.js 默认不带 charset，需显式调用res.set('Content-Type', 'text/html; charset=utf-8') - Tomcat：connector 缺少
URIEncoding="UTF-8"和useBodyEncodingForURI="true"，影响 GET 参数解码，间接导致页面渲染异常
调试方法：F12 → Network → 刷新 → 点开 HTML 请求 → 查看 Response Headers 中的 Content-Type 值，不是看 Preview 或 Response 标签页里的内容。
编辑器保存编码与文件真实编码不一致是高频陷阱
VS Code 右下角显示 “UTF-8”，不代表文件就是 UTF-8；它只是当前“以 UTF-8 解释这个文件”。如果原始文件是 GBK 编码，你强制“Reopen with Encoding”选 GBK，再“Save with Encoding”选 UTF-8，才算真正转码。否则只是用 UTF-8 视角去读 GBK 字节，结果必然乱码。
- Sublime Text：File → Save with Encoding → UTF-8（不是 “UTF-8 with BOM”）
- Notepad++：编码 → 转为 UTF-8（无 BOM）→ 保存
- 命令行批量修复：Linux 下可用
iconv -f gbk -t utf-8 input.html > output.html；注意先用file -i确认源编码 - Git 用户特别注意：Windows 提交 GBK 文件，Mac/Linux 拉取后自动按 UTF-8 解析，造成团队协作乱码；应在项目根目录加
.editorconfig强制charset = utf-8
JS/CSS 外部文件也必须是 UTF-8，且不能依赖 HTML 的 <meta>
<script src="app.js"></script> 和 <link rel="stylesheet" href="style.css"> 加载的是独立资源，它们的编码由各自文件的实际编码 + 对应的 HTTP Content-Type 头决定，HTML 页面里的 <meta charset> 对它们完全无效。
- 现象：HTML 正常，但 JS 中的中文提示、CSS 中的中文字体名（如
font-family: "微软雅黑"）显示为方块或乱码 - 排查：单独访问
http://yoursite.com/app.js，看浏览器地址栏是否自动下载；若显示乱码，说明 JS 文件本身不是 UTF-8，或服务端没返回Content-Type: application/javascript; charset=utf-8 - 修复：确保 JS/CSS 文件用 UTF-8（无 BOM）保存；Nginx/Apache 配置中对
.js、.css后缀也设置 charset，例如 Nginx：location ~ \.js$ { add_header Content-Type "application/javascript; charset=utf-8"; }
最易被忽略的一点：BOM 不仅影响 HTML，还会让 JS 解析失败（尤其 EF BB BF 开头的 JS 在某些旧环境会报 Unexpected token），而 CSS 中 BOM 可能导致规则失效。所以“UTF-8 without BOM”不是建议，是上线硬要求。
