乱码修复核心是UTF-8全链路对齐：文件实际编码、meta charset声明（须位于head最开头无BOM）、HTTP响应头Content-Type、模板引擎及服务器配置必须全部一致，任一环节错位即导致乱码。
乱码不是“修好就完事”，而是要让不同编辑器、浏览器、服务器和旧工具都能一致解码。核心就一条：UTF-8 全链路对齐，缺一不可。
meta charset 必须放在 最开头
浏览器解析 HTML 是流式读取的，<meta charset="UTF-8"> 越早出现，越早生效。如果前面有空格、注释、BOM 或其他标签，部分老浏览器（如 IE11）或解析器会跳过它，退回到默认编码（通常是 ISO-8859-1）。
- 错误写法：
<!-- 注释 --><meta charset="UTF-8">（注释导致失效） - 正确位置：紧跟
<head>开始，前面不能有任何字符（包括空行、空格、BOM） - VS Code 中可按
Ctrl+Shift+P→ 输入Change File Encoding→ 选UTF-8（非 UTF-8 with BOM），再保存，能清除隐藏 BOM
文件实际编码 ≠ meta 声明编码
很多人改了 <meta charset="UTF-8"> 就以为万事大吉，结果还是乱码——因为文件本身是 GBK 编码存的，浏览器用 UTF-8 解，字节对不上，自然显示 或 。
- 用
file -i filename.html（Linux/macOS）或PowerShell的Get-Content -Encoding UTF8 -Raw filename.html | Out-Null（Windows）验证真实编码 - Notepad++ 右下角显示的编码是“当前识别结果”，不等于“文件保存时用的编码”；务必点“编码 → 转为 UTF-8 无 BOM → 保存”
- VS Code 默认保存为 UTF-8（无 BOM），但若你曾手动选过 GBK，它会记住——每次保存前看右下角，确认是
UTF-8
服务端响应头优先级高于 meta
HTTP 响应头里的 Content-Type: text/html; charset=GBK 会直接覆盖 <meta charset="UTF-8">，哪怕 meta 写得再规范也没用。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置里检查是否有
charset gb2312;或缺失charset utf-8; - Apache 检查
.htaccess或主配置中是否含AddDefaultCharset GBK - Express 中用
res.set('Content-Type', 'text/html; charset=utf-8')显式设置，别依赖res.sendFile()默认行为 - Chrome DevTools → Network → 点开 HTML 请求 → Headers → Response Headers → 查看
content-type字段值
动态模板（Thymeleaf / EJS / PHP）需额外设编码
模板引擎在渲染时可能用自己的编码逻辑覆盖原始文件设置，尤其当模板被嵌套或继承时，<meta charset> 容易被挤到后面，或根本没被注入。
- Thymeleaf：在配置中加
templateResolver.setCharacterEncoding("UTF-8") - EJS：渲染时传入
{ encoding: 'utf8' }选项 - PHP：确保
header('Content-Type: text/html; charset=utf-8');在任何输出前调用，且 PHP 文件本身是 UTF-8 无 BOM - 关键验证点：查看浏览器里最终渲染出的 HTML 源码，确认
<meta charset="UTF-8">确实存在且位于<head>第一行
最容易被忽略的是「BOM 与无 BOM 的混用」：VS Code 默认无 BOM，记事本默认带 BOM，Git 在 Windows 上可能自动转 GBK，Nginx 静态服务又对 BOM 敏感——只要其中一环用了带 BOM 的 UTF-8，就可能触发某些解析器降级。统一用无 BOM 的 UTF-8，是最小意外成本的选择。
