HTML中文乱码核心是文件编码、meta charset声明、HTTP响应头三者未统一为UTF-8（无BOM）；需确认文件真实编码（非编辑器显示）、meta必须位于head最前、HTTP头优先级更高且不可冲突。
HTML 编码设置错误导致乱码，核心问题几乎总是“声明、存储、传输”三层不一致，而不是某一行代码写错了。 单独补一个 <meta charset="UTF-8"> 很可能没用；真正起效的前提是：文件本身是 UTF-8（无 BOM）、<meta charset> 在 最开头、HTTP 响应头也声明了 charset=utf-8（或至少不冲突）。
怎么确认 HTML 文件实际编码是不是 UTF-8？
编辑器显示的“UTF-8”只是它自己的猜测，不是事实。必须查原始字节：
- Linux/macOS：运行
file -i your.html，看输出是否含charset=utf-8；更准一点用head -c 4 your.html | xxd，若开头是ef bb bf就是带 BOM 的 UTF-8（应避免） - Windows PowerShell：运行
Get-Content your.html -Encoding Byte | Select -First 3，结果为239, 187, 191表示有 BOM - VS Code 右下角显示 “UTF-8” 时，点一下它 → 选 “Save with Encoding” → 明确选 “UTF-8”（注意不是 “UTF-8 with BOM”）
- Sublime Text：菜单 File → Save with Encoding → UTF-8
BOM 是隐形破坏者：它会让 PHP 的 header() 报错、Node.js 的 res.set() 失效、JS/CSS 解析出 Invalid or unexpected token。
<meta charset> 为什么写了也不生效？
常见失效原因不是语法错，而是位置或环境不满足解析条件：
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 必须出现在
开始后、任何其他标签（包括注释、空格、<title></title>）之前 —— 浏览器只扫描前 1024 字节找它，且只认第一个 - 双击打开 HTML（
file://协议）时，HTTP 响应头完全不存在，此时<meta charset>是唯一依据，但若文件本身不是 UTF-8，它就救不了 - 如果用了模板引擎（如 EJS、Thymeleaf），
<meta charset>可能被动态插入到中间，导致失效；应确保它在模板源码里就是的第一个子节点 -
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">已被 HTML5 废弃，且在file://下无效，不要用
HTTP 响应头和 <meta charset> 谁说了算？
响应头优先级高于 <meta charset>，但前提是它存在且合法：
- Chrome DevTools → Network → 点开 HTML 请求 → Headers → Response Headers → 查
content-type是否含charset=utf-8 - Nginx 配置中，
add_header Content-Type "text/html; charset=utf-8"是错的（会覆盖整个 header），正确写法是charset utf-8;放在 server 或 location 块里 - Apache：确保
AddDefaultCharset UTF-8已启用，且未被 .htaccess 覆盖 - Express：不能只用
res.sendFile()，必须显式加res.set('Content-Type', 'text/html; charset=utf-8') - PHP：在
echo或include任何输出前，调用header('Content-Type: text/html; charset=utf-8');，且文件不能含 BOM
最易忽略的一点：本地开发用 Live Server（VS Code 插件）或 Python 的 http.server 时，它们默认不发 charset，必须手动配置或换用支持 charset 的服务。
为什么改完还是乱码？重点检查这三处
很多修复失败，是因为只动了一层，其他层还在拖后腿：
- 外部 JS/CSS 文件本身不是 UTF-8：哪怕 HTML 正确，
<script src="app.js"></script>加载的 JS 若是 GBK 编码，也会触发解析错误，连带影响页面渲染 - 数据库连接没设 charset：PHP 的
mysqli_set_charset($conn, 'utf8mb4')、Node.js 的 MySQL 连接配置charset: 'utf8mb4'必须显式声明，否则接口返回中文仍是乱码 - 构建工具或部署脚本二次转码：Webpack、Vite 或 html-deploy 类工具若未配置编码，可能把 UTF-8 源文件转成 ISO-8859-1 输出，这时看源码正常，上线就乱
真正稳定的方案，是让所有环节都明确“只认 UTF-8，拒绝 fallback”。一旦发现某处偷偷用了 GBK 或 ISO-8859-1，就得从源头堵住，而不是靠浏览器猜。
