html中文乱码的根本原因是文件保存编码、meta charset声明、http响应头content-type三者至少一环未统一为utf-8；需逐一确认并修正。
HTML 中文变成乱码，不是“写了中文就自动错”，而是编码在**三个环节中至少断掉一环**：文件实际保存格式、<meta charset> 声明、HTTP 响应头 Content-Type。只要其中任一不统一为 UTF-8（且无干扰），浏览器就会 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 常是 ISO-8859-1），结果就是乱码。
VS Code 显示“GBK”却写了 <meta charset="UTF-8">？
这是最典型的表象矛盾。根本原因是：文件实际保存的编码不是 UTF-8，而是 GBK —— VS Code 只是“按你上次选的编码打开”，并不自动转码。你看到的 <meta charset="UTF-8"> 是写在 GBK 编码文件里的几个 ASCII 字符，但文件里真正的中文早已被存成 GBK 字节，浏览器按 UTF-8 解释这些字节，必然出错。
- 先确认当前文件真实编码：VS Code 状态栏右下角点编码名 → 选 Reopen with Encoding → 依次试
GBK、UTF-8，看中文是否正常显示 - 若
GBK下中文正常，说明文件确实是 GBK 编码；此时不要改<meta>，而是点状态栏 → Save with Encoding → 选UTF-8（注意：勾选 “UTF-8 with BOM” 在 Windows 下更稳） - 保存后，状态栏应显示
UTF-8（不含 “with BOM” 字样也行，但别显示 “GBK”）
<meta charset="UTF-8"> 放在
因为浏览器只扫描 HTML 前 1024 字节找 <meta charset>，如果它前面有 BOM、空行、注释或不可见字符，就可能被跳过。一旦错过，浏览器立刻 fallback。
- 确保
<meta charset="UTF-8">是内第一个标签，前面**不能有任何字符**（包括空格、换行、<!-- -->、BOM） - 用命令验证 BOM：Linux/macOS 运行
head -c 4 index.html | xxd，输出含ef bb bf就有 BOM；PowerShell 运行Get-Content index.html -Encoding Byte | Select -First 3，前三字节是239, 187, 191同样有 BOM - 有 BOM 时，要么删掉（用十六进制编辑器或
sed -i '1s/^\xEF\xBB\xBF//' index.html），要么确保它紧挨着<meta charset>前面（BOM +<meta>必须在前 1024 字节内） - 别写
<meta charset="utf8">或<meta charset="UTF8">—— 浏览器只认标准写法UTF-8
用 file:// 打开正常，但 HTTP 服务下乱码？
因为 file:// 协议没有 HTTP 响应头，浏览器只能依赖 <meta>；而走 HTTP（如 http://localhost:3000）时，服务器返回的 Content-Type 响应头会**直接覆盖** <meta>，优先级更高。
- 用浏览器 F12 → Network → 刷新 → 点 HTML 请求 → 查看 Response Headers 里的
Content-Type - 如果值是
text/html; charset=iso-8859-1或charset=gbk，问题就在服务端 - Nginx 配置需加
charset utf-8;（在server或location块内），别用add_header Content-Type（会重复） - Node.js/Express 中，
res.set("Content-Type", "text/html; charset=utf-8")必须在res.send()之前调用 - Python
http.server默认不发 charset，必须自己加响应头或换用支持 charset 的开发服务器（如 Live Server）
真正卡住人的地方，往往不是“该写什么”，而是“文件到底存成了什么”和“服务器到底发了什么”。<meta charset> 只是最后一道保险，它救不了编码源头就错的文件，也压不住服务器硬塞过来的错误 Content-Type。动手前，先用命令或开发者工具把这两件事钉死。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
