html中文乱码是编码链断裂所致，需同步检查文件实际编码（如vs code右下角显示）、位置与写法（必须在内前1024字节且唯一）、http响应头content-type、服务器配置（nginx/apache/node.js等）及编辑器隐式转码行为。
HTML 中文乱码不是单点问题，而是编码链断裂的结果：文件保存格式、<meta charset> 声明、HTTP 响应头、服务器配置、编辑器默认行为，任一环节不一致就会出错。
检查 HTML 文件实际保存编码
浏览器看到的乱码，往往源头在文件本身。VS Code 或 Sublime Text 打开 HTML 文件时右下角显示的编码（如 GBK、ANSI、UTF-8 with BOM）就是真实保存格式。如果显示为 GBK 或 ISO-8859-1，但页面又写了 <meta charset="UTF-8">，那必然乱码。
- 用 VS Code 打开文件 → 点右下角编码名称 → 选
Save with Encoding→ 强制选UTF-8（不要选UTF-8 with BOM） - 用命令行验证：执行
file -i filename.html（Linux/macOS）或xxd -l 8 filename.html查看开头是否为ef bb bf（BOM） - 若开头有 BOM 且页面仍乱码，说明某些旧版服务器或代理会把 BOM 当作响应体开头，导致
Content-Type头解析失败
确认 <meta charset> 位置与写法
<meta charset="UTF-8"> 必须出现在 内、且是前 1024 字节中第一个 <meta> 标签；写成 <meta charset="utf8"> 或 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 虽然部分浏览器能 fallback，但不推荐——前者非标准写法，后者在 HTML5 中已被明确标记为过时。
- 必须写在
<title></title>、<script></script>、<style></style>等任何可能含非 ASCII 字符的标签之前 - 不能写两遍，也不能和
http-equiv版本共存 - 如果页面由模板引擎（如 Thymeleaf、Jinja）生成，要确认该标签未被动态删减或错位插入
比对 HTTP 响应头中的 Content-Type
当通过 http:// 访问时，浏览器优先信任响应头里的 Content-Type，而非 <meta>。打开 DevTools → Network → 刷新页面 → 点 HTML 请求 → 查看 Response Headers 中是否有类似 Content-Type: text/html; charset=GBK 的字段。如果有，说明服务器覆盖了你的 <meta> 设置。
- Nginx 配置需含
charset utf-8;（放在http、server或location块中） - Apache 需在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8 - Python 的
http.server默认发charset=iso-8859-1，必须自行设置响应头 - 本地用
file://协议打开时，浏览器完全忽略响应头，只认<meta>，此时乱码基本锁定为文件编码或编辑器保存问题
排查编辑器与构建工具的隐式转换
很多前端工具链会在保存或构建时“好心”转码。比如 Webpack 的 html-webpack-plugin 若未配置 minify: { removeComments: true }，可能误删 <meta charset>；某些 IDE 的“自动清理空格”功能会把 UTF-8 文件重存为系统默认编码（Windows 上常是 GBK）。
- 检查构建产物（如
dist/index.html）是否仍含正确<meta charset="UTF-8">和无 BOM 的 UTF-8 编码 - 禁用编辑器的“保存时自动转码”选项（VS Code 中关闭
"files.autoGuessEncoding"） - 若用 Git，注意
.gitattributes是否设置了* text=auto导致 Windows 换行符 + 编码混合污染
真正难缠的乱码，往往卡在「你以为改对了 meta，其实文件早被编辑器悄悄存成了 GBK」或者「Nginx 发了 charset=GBK，你却只盯着 HTML 源码」——动手前，先用 file 和 DevTools Network 验证真实字节和响应头，比反复刷新网页有效得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
