HTML中文乱码主因是构建流程中文件实际编码（如UTF-8 BOM）、<meta charset>未生效（被注释/空格/BOM挤出前1024字节）及HTTP响应头Content-Type错误覆盖三者叠加，需按响应头→源码结构→字节流顺序排查。
打包后 HTML 中文乱码，基本不是“浏览器没认出来”，而是构建流程中某个环节悄悄改了编码或覆盖了声明。关键要盯住三个地方：文件实际字节、meta charset 是否生效、HTTP 响应头是否被注入错误 charset。
检查打包产物的文件实际编码（BOM / UTF-8 with BOM 是高频坑）
很多构建工具（如 Webpack、Vite）默认不处理 HTML 文件编码，直接复制源文件。如果原始 index.html 是用 VS Code 保存为 UTF-8 with BOM，或被 Windows 记事本“污染”过，那打包后的文件开头就藏着 EF BB BF 三个字节 —— 浏览器在解析前 1024 字节时会跳过它，导致 <meta charset="UTF-8"> 被判定为“太晚出现”，回退到 GBK。
- 用命令行快速验证：
head -c 4 dist/index.html | xxd，输出含ef bb bf就确认有 BOM - VS Code 打开打包后的
dist/index.html，右下角看编码显示；若为UTF-8 with BOM，点击它 →Save with Encoding→ 选UTF-8（不含 BOM） - Webpack 用户可在
html-webpack-plugin配置中加minify: { removeComments: true, collapseWhitespace: true }，但更治本的是源头统一保存为无 BOM UTF-8
确认 <meta charset="UTF-8"> 在
构建插件（比如 html-webpack-plugin 或 Vite 的 html 插件）可能自动注入脚本、preload 标签，或拼接模板时把注释、空行、甚至变量占位符塞到了 <meta> 前面。只要它不是 的第一个非空白节点，就大概率失效。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 打开打包后的
dist/index.html，手动查看源码：光标定位到开始，确认紧跟着就是<meta charset="UTF-8">，中间不能有换行、空格、<!-- comment -->或任何其他标签 - 避免在模板里写成：
\n <!-- inject -->\n <meta charset="UTF-8">—— 这个换行和空格已足够让浏览器忽略它 - 如果是 EJS / Pug 等模板引擎生成 HTML，检查模板是否在
<meta>前插入了不可见字符或条件逻辑输出
验证 HTTP 响应头中的 Content-Type 是否被覆盖
本地用 file:// 打开时只依赖 <meta>，但部署后走 HTTP 协议，服务器返回的响应头 Content-Type: text/html; charset=xxx 优先级永远高于 HTML 内部声明。常见陷阱是 Nginx/Apache 配置了全局 charset gbk，或者 Express 的 res.sendFile() 没显式设 charset。
立即学习“前端免费学习笔记（深入）”；
- 部署后打开浏览器开发者工具 →
Network→ 刷新 → 找到document类型的主 HTML 请求 → 看Response Headers里的Content-Type - 若值为
text/html; charset=gbk或压根没charset子句（只有text/html），问题就在这儿 - Nginx 配置需确保有
charset utf-8;（注意分号），且不在location块里被低优先级规则覆盖 - Vite 预览服务器（
vite preview）默认不发 charset 头，此时<meta>生效；但真实 Nginx/CDN 环境必须靠服务端头兜底
真正难排查的，往往是三者叠加：文件带 BOM + <meta> 被模板引擎挤到第二行 + Nginx 又配了 charset gbk。建议按顺序查：先看响应头，再扒打包后 HTML 源码，最后用 xxd 确认字节流 —— 不要一上来就重装插件或改构建配置。
