HTML乱码根本原因是meta charset声明、文件实际保存编码、HTTP响应头三者不一致；浏览器优先采用响应头charset，其次BOM，最后才是meta标签，三者必须统一为UTF-8（无BOM）才能彻底解决。
HTML 编码本身不能“提升”乱码问题——它只是声明编码方式的手段；真正起作用的是 meta charset 声明、文件实际保存编码、HTTP 响应头三者是否一致。不一致，就必然乱码。
为什么 meta charset="UTF-8" 写了还是乱码？
因为浏览器只在「找不到更权威编码信息」时才信任这个标签。它排第三顺位，优先级低于：
- HTTP 响应头里的
Content-Type: text/html; charset=UTF-8 - 文件 BOM（Byte Order Mark）：如果用记事本保存为 UTF-8 带 BOM，Chrome 会强制按 UTF-8 解析，哪怕
meta写的是gb2312 - 浏览器手动选错编码（比如右键 → “编码” → 选了 GBK）
所以光写 <meta charset="UTF-8"> 不够，得确认文件真以 UTF-8 无 BOM 形式保存（VS Code 默认是，记事本默认是带 BOM 的 UTF-8）。
记事本保存 HTML 后中文全变成 或 æ–‡ 字？
这是最典型的新手陷阱：记事本默认用系统区域设置编码（如 Windows 简体中文版是 GBK）保存文件，但你又写了 <meta charset="UTF-8">，导致“声明 UTF-8，实际存 GBK”，浏览器按 UTF-8 解析 GBK 字节流，必然出现 æ–‡ 类乱码。
立即学习“前端免费学习笔记（深入）”；
解决方法只有两个，且必须同时做：
- 在记事本中：「另存为」→ 编码下拉菜单选
UTF-8（不是“UTF-8-BOM”或“ANSI”）→ 保存 - 在 HTML 中保留
<meta charset="UTF-8">，且放在最前面（越靠前越早生效）
如果用 VS Code / Sublime Text，直接看右下角编码显示，点它 → 「Save with Encoding」→ 选 UTF-8 即可。
charset=gb2312 和 charset=GBK 能混用吗？
不能。虽然 GBK 是 GB2312 的超集，但它们是不同编码标准：
-
charset="gb2312"声明后，浏览器只尝试解析 GB2312 范围内的字，超出部分（如“镕”“煊”等较新汉字）会显示为 -
charset="GBK"才能正确解析 GBK 全字符集，但注意：HTML5 规范不承认GBK为合法值，部分浏览器（如新版 Edge）可能降级处理或报 warning - 更稳妥的做法是统一用
UTF-8，并确保后端、数据库、文件、响应头全部对齐
如果你必须兼容老系统（比如某些政府内网 IE6），才考虑 <meta http-equiv="Content-Type" content="text/html; charset=GB2312">，但这是退化方案，不是推荐路径。
服务器没配 AddDefaultCharset 就一定乱码？
不一定，但风险极高。Apache 默认不发 Content-Type 头里的 charset，Nginx 默认也不发。这时候浏览器只能靠 meta 或 BOM 推断——而推断失败率很高，尤其当页面有外链 CSS/JS、或含重定向时。
实操建议：
- Apache：在站点配置或
.htaccess加AddDefaultCharset UTF-8 - Nginx：在
http或server块加charset utf-8; - Node.js（Express）：
res.set('Content-Type', 'text/html; charset=utf-8') - PHP：在输出 HTML 前加
header('Content-Type: text/html; charset=utf-8');
注意：如果 HTTP 响应头已含 charset，meta charset 会被忽略——所以调试时务必用浏览器开发者工具的 Network 面板，点开 HTML 请求，看 Response Headers 里的 content-type 值是否含 charset=utf-8。
乱码问题从来不是单点故障，而是编码链条上任意一环断裂的结果。最容易被忽略的是：文件保存编码 ≠ meta 声明编码 ≠ HTTP 响应头编码。调的时候，别只盯 HTML 源码，三个地方必须同步验证。
