核心原因是浏览器未识别文件实际编码而回退至系统默认编码（如Windows的GBK），与文件真实编码（如UTF-8）不匹配；须通过字节验证（BOM、file命令等）确认真实编码，并确保文件无BOM、紧贴开头且HTTP响应头（若适用）一致。
直接打开本地 index.html 文件出现中文乱码，核心原因只有一个：浏览器没识别出文件实际编码， fallback 到了系统默认编码（Windows 通常是 GBK），而文件本身是 UTF-8（或反之）。解决它不靠猜，靠验证和对齐。
确认 HTML 文件真实编码格式
别信编辑器右下角显示的“UTF-8”——那只是编辑器当前“怎么读它”，不是文件“本来存成啥”。必须查字节：
- VS Code：右下角点击编码名称 → 选
Reopen with Encoding，依次试UTF-8、GBK、ISO-8859-1，哪个能正常显示中文，哪个就是真实编码 - Linux/macOS 终端：
file -i index.html，看输出里的charset=值；或head -c 4 index.html | xxd，若开头是ef bb bf就有 BOM - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果为239 187 191即含 BOM
常见陷阱：VS Code 默认 Windows 下用 UTF-8 with BOM 保存，但 BOM 会干扰 <meta charset> 解析 —— 如果文件头有 BOM，<meta charset="UTF-8"> 很可能完全失效。
<meta charset> 必须紧贴
HTML 解析器只扫描前 1024 字节找 charset 声明，且要求它出现在 标签内、且前面不能有任何字符（包括 BOM、空格、换行、注释、<script></script> 或 <link>）。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确位置：
<head> <meta charset="UTF-8"> <title>测试页面</title> </head>
- ❌ 失效写法：
<!-- 注释 --><meta charset="UTF-8">、<script></script><meta charset="UTF-8">、<meta charset="UTF-8">（开头空格） - ⚠️ 注意：
<meta charset="utf8">错误（少横线）、<meta charset="UTF8">错误（缺连字符）、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">在 HTML5 中已不推荐，且易被 HTTP 响应头覆盖
HTTP 响应头比 <meta> 优先级更高
当你通过 http:// 或 https:// 访问页面（比如用 python -m http.server、Nginx、PHP 内置服务器），服务器返回的 Content-Type 响应头会直接覆盖 HTML 里的 <meta charset>。
- Chrome F12 → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type值 - 如果它是
text/html; charset=gbk或text/html; charset=iso-8859-1，哪怕你写了<meta charset="UTF-8">也白搭 - 常见服务配置：
– Nginx：在location块加add_header Content-Type "text/html; charset=utf-8";（注意不是charset utf-8;，那是针对静态文件的 MIME 类型映射）
– Node.js/Express：res.set("Content-Type", "text/html; charset=utf-8")必须在res.send()前调用
– PHP：header("Content-Type: text/html; charset=utf-8");必须在任何输出（包括空格、BOM）之前执行
本地 file:// 协议下唯一依赖 <meta charset>
双击打开 HTML 文件走的是 file:// 协议，没有 HTTP 响应头，此时浏览器完全依赖 <meta charset> 和文件自身编码。这也是最容易出问题的场景。
- 最稳组合：文件用纯
UTF-8（无 BOM）保存 +<meta charset="UTF-8">紧贴开头 - VS Code 保存时务必选
UTF-8（不是UTF-8 with BOM），否则 BOM 会卡在<meta>前面导致解析失败 - 如果必须用 GBK 编码（如老系统兼容），则文件存为
GBK，<meta>改为<meta http-equiv="Content-Type" content="text/html; charset=GBK">（HTML5 不支持charset="GBK"简写）
真正容易被忽略的是：BOM 不是“看不见就不存在”，它是实实在在的三个字节，会把 <meta> 推到扫描范围之外；而 HTTP 响应头一旦存在，<meta> 就彻底退居二线 —— 这两点不验证清楚，改十遍 <meta> 都没用。
