必须确保<meta charset="UTF-8">正确书写且位于<head>最前面，文件保存为无BOM的UTF-8，服务器响应头Content-Type未覆盖编码声明，并统一外部JS/CSS文件编码。
检查 <meta charset> 是否缺失或写错
浏览器默认用 ISO-8859-1 解析 HTML，没声明编码时中文必然乱码。最常见错误是漏写、写成 charset=gbk（尤其在旧项目里），或位置不对（必须在 <head> 最前面，且早于任何含中文的标签或内联 <script>）。
正确写法只有一种：<meta charset="UTF-8">。注意：不要写 charset=utf8（缺横线）、charset=UTF8（大小写不敏感但惯例全大写加横线），也不要写成 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（冗余且易被忽略）。
确认文件实际保存编码与 charset 声明一致
编辑器显示“UTF-8”不代表文件真是 UTF-8 编码。VS Code、Sublime、Notepad++ 都可能用“UTF-8 with BOM”保存，而 BOM 会干扰某些服务器（如 Nginx）或 JS 解析；也可能误存为 GBK/GB2312，此时即使写了 UTF-8 声明，浏览器仍按声明强行解码，结果是乱码。
验证方法：
立即学习“前端免费学习笔记（深入）”；
- 用 VS Code 右下角查看当前编码，点击切换 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - 用命令行
file -i index.html（Linux/macOS）或 PowerShellGet-Content index.html -Encoding Byte | Select -First 3查看前几个字节是否为ef bb bf（BOM） - 若发现 BOM 或非 UTF-8，另存为无 BOM 的 UTF-8 并重启服务
排查服务器响应头是否覆盖了 <meta>
HTTP 响应头里的 Content-Type 优先级高于 <meta charset>。如果服务器返回 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了 UTF-8，浏览器也按响应头来。
检查方式：
- 浏览器开发者工具 → Network → 刷页面 → 点 HTML 请求 → Headers → Response Headers → 找
Content-Type - 本地用
curl -I http://localhost/index.html看响应头 - 常见诱因：Nginx 默认不设 charset；Apache 的
AddDefaultCharset设成了GBK；Node.js 的res.setHeader('Content-Type', 'text/html')没带charset
修复：Nginx 加 charset utf-8;；Apache 关闭 AddDefaultCharset 或设为 off；Node.js 显式写 res.setHeader('Content-Type', 'text/html; charset=UTF-8')。
留意外部资源（JS/CSS）引入时的编码问题
HTML 本身正常，但通过 <script src="app.js"> 或 <link href="style.css"> 加载的文件若编码不一致，也会导致其中的中文注释、字符串、CSS 内容乱码——尤其是动态插入 DOM 的文本，容易误判为 HTML 问题。
排查要点：
- 单独访问
app.jsURL，看浏览器地址栏是否提示“编码错误”或内容直接显示为方块 - 检查这些文件本身的保存编码，确保也是无 BOM 的 UTF-8
- JS 中避免用
document.write输出未转义中文（已废弃，且易触发二次解析问题） - CSS 中中文类名、属性值（如
content: "编辑";）同样依赖文件编码，别用 GBK 存 CSS 却在 UTF-8 页面里引用
真正卡住的时候，往往不是某一处错了，而是 meta、文件编码、响应头、外部资源四者中两处以上不一致。建议按顺序逐项排除：先看响应头，再验文件编码，再查 meta 位置和拼写，最后盯 JS/CSS 文件本身——别跳步。
