HTML中文乱码需四者对齐：文件存储编码、<meta charset>、HTTP Content-Type响应头、外部资源编码，缺一不可；首关是确认文件是否UTF-8无BOM，用file -i或PowerShell查BOM，VS Code须选“UTF-8”而非“UTF-8 with BOM”，<meta>必须紧贴<head>开头且前无任何字符，HTTP场景下响应头优先级高于<meta>。
HTML 中文乱码不是单一环节出错，而是编码链上任一环节断开都会触发——文件存储编码、<meta charset>、HTTP Content-Type 响应头、外部资源（JS/CSS）编码，四者必须全部对齐为 UTF-8 才能稳定显示中文。
怎么确认 HTML 文件本身是不是 UTF-8 编码
乱码的第一关永远是文件磁盘存储格式。VS Code 显示右下角编码名称（如 “GBK” 或 “UTF-8 with BOM”）只是编辑器猜测，不可全信。
- Linux/macOS 运行：
file -i index.html，输出含charset=utf-8才算实锤；若为charset=gbk，说明保存时选错了 - Windows 用 PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若输出239 187 191（即ef bb bf），表示带 BOM；BOM 虽属 UTF-8，但会干扰 PHP/Node.js 的 header() 输出 - Sublime Text 或 Notepad++ 保存时务必选 “UTF-8”（Notepad++ 要避开 “UTF-8-BOM”）；VS Code 默认 Windows 下存为 “UTF-8 with BOM”，需手动点右下角编码 → “Save with Encoding” → 选 “UTF-8”（不含 BOM）
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器只扫描 HTML 前 1024 字节找 <meta charset>，且一旦遇到 BOM、注释、空行或非 ASCII 字符（比如中文注释），就可能提前终止扫描，退而使用系统默认编码（Windows 是 GBK）。
-
<meta charset="UTF-8">必须紧贴<head>开始，前面不能有任何字符（包括空格、换行、<!-- 注释 -->） - 禁止写成：
<meta charset="utf8">（缺横杠）、<meta charset="UTF8">（大小写不规范）、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（HTML5 已不推荐） - 验证方式：用浏览器 F12 → Network → 点击 HTML 请求 → Headers → Response Headers 查看
Content-Type是否存在；若不存在，说明服务器没发头，此时才完全依赖<meta>，它就更不能出错
HTTP 响应头 Content-Type 和 <meta> 谁优先
当通过 http:// 或 https:// 访问时，HTTP 响应头中的 Content-Type: text/html; charset=UTF-8 优先级高于 <meta>；但用 file:// 直接双击打开 HTML，则完全忽略响应头，只认 <meta>。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置需在
server或location块中加：add_header Content-Type "text/html; charset=utf-8";（注意：不是charset utf-8;，那是针对静态文件的默认值，不覆盖已有的 Content-Type） - Express 中必须在
res.send()前调用：res.set("Content-Type", "text/html; charset=utf-8");；若用res.sendFile()，它默认不设 charset，必须手动补 - Apache 的
AddDefaultCharset UTF-8只对纯文本生效，对text/html类型无效，要配合mod_headers用Header set Content-Type "text/html; charset=utf-8"
为什么 CSS/JS 里中文也乱码，和 HTML 没关系
浏览器加载 <script src="app.js"></script> 或 <link rel="stylesheet" href="style.css"> 时，会为每个资源单独发起请求，并各自检查其响应头或文件编码。HTML 的 <meta> 对它们完全无效。
- 确保
app.js和style.css文件本身也是 UTF-8 无 BOM 编码（同样用file -i或 VS Code 编码识别验证） - 检查这些资源的 HTTP 响应头是否也返回了
Content-Type: ... charset=utf-8；Nginx 默认对.js和.css不设 charset，需显式配置：add_header Content-Type "application/javascript; charset=utf-8";（JS）或add_header Content-Type "text/css; charset=utf-8";（CSS） - 避免在 CSS 中写
content: "你好";却用 GBK 保存该 CSS 文件——这种“混合编码”现场极难排查，建议所有前端资源统一走 UTF-8 + 无 BOM 流程
最易被忽略的是：本地双击 file:// 打开时一切正常，部署到 Nginx 后却乱码，往往是因为 Nginx 没配响应头，而浏览器在 HTTP 场景下直接无视了 <meta>；反过来，Nginx 配了头但文件存成了 GBK，也会覆盖 meta 的效果。二者必须同步验证，缺一不可。
