html乱码的根本原因是编码链路不一致，而非html本身支持乱码；浏览器优先按http响应头content-type解码，其次才用，且文件保存编码、bom、外部资源及服务器配置均需统一为utf-8无bom。
HTML 编码本身不“支持乱码”，乱码是编码不一致导致的解码失败现象，不是 HTML 的功能或特性。
为什么 <meta charset="UTF-8"> 写了还是乱码
常见错误现象：HTML 文件里明明写了 <meta charset="UTF-8">，但中文仍显示为方块、问号或一堆乱符。
根本原因在于浏览器实际解码时，并不只看这行标签——它优先信任 HTTP 响应头里的 Content-Type，其次才 fallback 到 <meta charset>。如果服务器返回的是 Content-Type: text/html; charset=GBK 或干脆没带 charset，<meta charset="UTF-8"> 就会被忽略。
- 用浏览器 DevTools 的 Network 标签页打开 HTML 请求，检查 Response Headers 中的
Content-Type值是否含charset=utf-8 - 本地双击打开（
file://协议）时，浏览器无响应头，此时才真正依赖<meta charset>，但前提是文件本身保存为 UTF-8 -
<meta charset>必须放在内且尽可能靠前，最好作为第一个子元素；若前面有注释、空格或 BOM 字节，部分旧浏览器可能跳过识别
文件保存编码 ≠ HTML 声明编码
编辑器里选了“UTF-8”，不代表文件真是 UTF-8。尤其 VS Code、Notepad++ 默认可能保存为 UTF-8 with BOM，而 BOM（EF BB BF）会出现在文件开头，被某些后端（如 PHP）或构建工具误读，导致输出 HTML 时在 前多出不可见字符，进而让 <code><meta charset> 失效。
- 用命令行检查：运行
hexdump -C yourfile.html | head -n 1，若开头是ef bb bf，说明有 BOM - Notepad++：编码 → 转为 UTF-8（无 BOM）格式
- VS Code：右下角点击编码名称 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - Sublime Text：File → Save with Encoding → UTF-8
外部资源（JS/CSS/JSON）也得统一 UTF-8
即使 HTML 主体正常，引入的 <script src="app.js"></script> 或 <link href="style.css"> 如果自身不是 UTF-8 编码，浏览器加载后解析其中的中文字符串（比如 alert 文字、CSS 注释、JSON 键名）仍会乱码。
- 检查 JS/CSS 文件的实际编码，方法同 HTML：用编辑器确认并另存为 UTF-8（无 BOM）
- 不推荐在
<script></script>标签上硬加charset="UTF-8"属性（已废弃且不可靠），应确保文件和服务端响应头一致 - Ajax/fetch 加载 JSON 时，服务端必须返回
Content-Type: application/json; charset=utf-8，否则responseText解析可能错位
服务器配置常被忽略的细节
Nginx 和 Apache 默认不强制发送 charset=utf-8，尤其当使用静态文件服务时，容易遗漏这一环。
- Nginx：在
server或location块中加charset utf-8;（注意不是charset UTF-8;，小写即可） - Apache：在
.htaccess或主配置中加AddDefaultCharset UTF-8；若已有其他AddDefaultCharset指令，需确认它未被覆盖 - Node.js（如 Express）：不要只设
res.set('Content-Type', 'text/html')，要写全res.set('Content-Type', 'text/html; charset=utf-8')
最容易被忽略的是：BOM 不可见、响应头看不见、外部资源各自为政。三者只要有一处脱节，乱码就可能出现，而且问题往往不在 HTML 本身，而在它所依赖的整个链路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
