根本原因是文件实际保存编码与HTML声明编码不一致，如文件用GBK保存却声明UTF-8，或反之；需统一编辑器保存编码、标签（置于最前）、HTTP响应头charset及无BOM，四者缺一不可。

为什么浏览器打开 index.html 显示乱码

根本原因几乎都是文件实际保存的编码格式和 HTML 声明的编码不一致。比如文件用 GBK 保存，但 <meta charset="UTF-8"> 却告诉浏览器“这是 UTF-8”，浏览器硬按 UTF-8 解码，自然出现乱码。反过来（文件存为 UTF-8，但 meta 写成 GBK）也会乱。

确认并统一 index.html 的真实编码格式

别只看编辑器右下角显示——有些编辑器（如老版 Notepad、某些 Sublime 配置）会“假装”识别编码，实际保存时仍用系统默认编码。必须验证：

• 用 VS Code 打开，右下角点击编码名称（如 GBK 或 UTF-8 with BOM），选 Save with Encoding → UTF-8（注意选无 BOM 版本）
• 用记事本打开 → “另存为”，在底部“编码”下拉框中明确选 UTF-8（不是 ANSI 或 UTF-8-BOM），再保存
• 检查 HTML 中的 <meta> 标签是否匹配：<meta charset="UTF-8"> 必须存在且位于 最前面

常见陷阱：BOM 和服务器响应头冲突

即使文件存为 UTF-8，如果带 BOM（字节顺序标记），部分旧浏览器或某些服务器（如 Nginx 默认配置）可能把 BOM 当作响应正文开头，导致 Content-Type 头解析异常，或 JS/CSS 加载失败。同时，若服务器返回了 Content-Type: text/html; charset=GBK，它会直接覆盖 HTML 中的 <meta charset>，浏览器以响应头为准。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 用命令行检查是否有 BOM：xxd index.html | head -1，若输出开头是 00000000: efbb bf...，说明有 UTF-8 BOM，需转为无 BOM UTF-8
• 用浏览器开发者工具 → Network → 刷新页面 → 点开 index.html → 查看 Response Headers 中的 Content-Type，确认是否含 charset=utf-8
• 本地双击打开（file:// 协议）时，浏览器完全依赖 <meta charset>，此时 BOM 影响更大，务必去掉

编辑器和构建工具的隐性干扰

Webpack/Vite 等工具读取 HTML 模板时，若未显式指定编码，可能按 Node.js 默认（通常是 UTF-8）处理，但如果源文件本身是 GBK，就会出错。VS Code 的 files.encoding 设置只是编辑时行为，不改变已存文件的实际字节。

立即学习“前端免费学习笔记（深入）”；

• Vite 项目中，确保 index.html 文件本身是无 BOM UTF-8；Vite 不会自动转码 HTML 文件
• Sublime Text 用户：菜单 File → Save with Encoding → UTF-8，避免勾选 “Add BOM”
• Git 用户注意：git config --global core.autocrlf true 不影响编码，但 git config --global core.safecrlf warn 可提醒编码异常

真正卡住人的往往不是“怎么设 UTF-8”，而是文件、meta、HTTP 响应头、编辑器缓存这四者没对齐——尤其本地测试时绕过服务器，file:// 协议下连响应头都没有，全靠文件字节 + meta 标签，这里出一点偏差就立刻乱码。