HTML乱码主因是<meta charset>缺失、错位或与文件编码不一致；必须置于<head>最前，且文件保存为UTF-8无BOM；HTTP响应头Content-Type的charset优先于meta标签。
HTML文档显示乱码，90% 是 <meta charset> 缺失、错位或与文件实际编码不一致导致的。浏览器在没收到明确指示时，会 fallback 到 ISO-8859-1 或 Windows-1252，中文直接变问号或方块。
为什么 <meta charset="UTF-8"> 必须放在 <head> 最前面
浏览器解析 HTML 是流式进行的，一旦遇到非 ASCII 字符（比如中文标题、注释里的汉字），而此时还没读到 <meta charset>，就会用默认编码解码——这个过程不可逆。哪怕后面写了正确的 <meta charset="UTF-8">，前面已错的部分也不会重绘。
- 必须紧贴
<head>开始，前面不能有空格、换行、注释或<title> - 实测：在
<title>后面写<meta charset>，<title>里的中文大概率乱码 - IE 要求该标签必须出现在前 1024 字节内，所以别在
<head>里堆一堆<script>或<link>再写它
文件保存为 UTF-8 但带 BOM 会出什么问题
BOM（EF BB BF）是三个隐藏字节，出现在文件开头。多数现代编辑器默认保存为 “UTF-8 with BOM”，但它会导致两个典型故障：
-
<script>或<style>标签前如果紧挨着 BOM，JS/CSS 解析器可能把 BOM 当作非法字符，报Uncaught SyntaxError: Invalid or unexpected token - PHP 或 Node.js 服务端输出 HTML 前若已有 BOM，会提前触发 HTTP 响应头发送，导致后续
header()或res.set()失败 - 用
file -i your.html（Linux/macOS）或 Notepad++ 的“编码”菜单可快速确认是否含 BOM；VS Code 保存时选 “UTF-8”（不含 “with BOM” 字样）
HTTP 响应头的 Content-Type 和 <meta charset> 谁优先
HTTP 响应头里的 Content-Type: text/html; charset=utf-8 永远优先于 HTML 中的 <meta charset>。这是规范强制行为，不是“建议”。
立即学习“前端免费学习笔记（深入）”；
- 当你用 Chrome DevTools 的 Network 面板查看 HTML 请求，点开 Response Headers，如果
content-type显示charset=gbk或压根没charset，那<meta charset="UTF-8">就是摆设 - Nginx 需在
server或location块加charset utf-8;；Apache 用AddDefaultCharset UTF-8；Express 中不要只靠res.sendFile()，显式调用res.set('Content-Type', 'text/html; charset=utf-8') - 本地双击打开 HTML（
file://协议）时，HTTP 头不存在，此时才完全依赖<meta charset>
动态生成 HTML 时容易漏掉的编码环节
模板引擎（如 EJS、Jinja2、Thymeleaf）或 Python/Node.js 拼接 HTML 字符串时，<meta charset> 很容易被写死在模板里，但输出时却忽略了响应头或文件写入编码。
- Python 用
open(..., "w", encoding="utf-8")写 HTML 文件，否则默认用系统编码（Windows 是 GBK） - requests 获取网页后，
response.text可能因response.encoding推断错误而乱码，应显式设response.encoding = "utf-8"或用response.content.decode("utf-8") - 后端返回 JSON 数据给前端渲染，也要确保 API 响应头是
Content-Type: application/json; charset=utf-8，否则fetch().then(r => r.json())可能失败
真正棘手的不是某一处没设 UTF-8，而是多层之间编码不一致：文件存的是 UTF-8，但 Nginx 发送时加了 charset gbk；或者 JS 动态插入 DOM 的字符串来自一个没声明编码的 AJAX 响应。排查时得一层层看 —— 文件本身、HTTP 头、模板逻辑、外部资源引用 —— 少一环，中文就少一半。
