根本原因是file://协议下浏览器忽略http响应头，仅依赖文件编码与匹配；须用记事本另存为utf-8（无bom），且必须为内首个子节点。
本地直接双击打开 HTML 文件出现中文乱码，根本原因只有一个：file:// 协议下浏览器**完全忽略 HTTP 响应头**，只依赖文件本身的字节序列 + <meta charset> 标签，而这两者又极易不匹配。
记事本保存为 UTF-8（无 BOM）最稳妥
Windows 自带记事本默认用 GBK 保存，这是乱码主因。必须手动改：
- 用记事本打开 HTML 文件 → 点「文件」→ 「另存为」
- 在「编码」下拉菜单中，**必须选「UTF-8」**（不是「UTF-8-BOM」，也不是「ANSI」）
- 确认文件名后缀仍是
.html，点击保存 - 关闭再重开，乱码通常立刻消失
注意：记事本里「UTF-8」选项实际就是无 BOM 的 UTF-8；「UTF-8-BOM」会额外写入 EF BB BF 三个字节到文件开头，反而可能让某些老浏览器或工具误判。
<meta charset="UTF-8"> 必须紧贴
即使文件已存为 UTF-8，如果 <meta charset="UTF-8"> 写错位置，浏览器照样 fallback 到 GBK：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 它必须是
标签内的**第一个子节点**，前面不能有任何字符（包括空格、换行、注释、BOM） - 错误写法：
\n <!-- 注释 -->\n <meta charset="UTF-8">→ 失效 - 正确写法：
<meta charset="UTF-8">（中间无换行、无空格、无注释） - 大小写敏感：
utf8、UTF8、utf-8全部无效，只能是UTF-8
验证文件真实编码是否为 UTF-8（无 BOM）
别信记事本右下角显示的「编码」，它经常误判。用命令行确认更可靠：
- PowerShell 中运行：
Get-Content yourfile.html -Encoding Byte | Select -First 3 - 如果输出是
239 187 191，说明有 BOM → 需重存为「UTF-8」（去掉 BOM） - 如果输出是其他数字（比如
60 63 120），大概率是无 BOM 的 UTF-8 或 GBK → 再结合内容判断 - Linux/macOS 用：
head -c 3 yourfile.html | xxd，看是否有ef bb bf
记事本本身无法查看十六进制，所以这一步不能跳过——很多所谓「已存为 UTF-8」的文件，其实只是记事本自作主张显示了错误的编码名称。
为什么不用 <meta http-equiv="Content-Type">？
这个写法在 HTML5 中已废弃，且对本地文件完全无效：
- 它模拟 HTTP 响应头，但
file://下根本没有响应头可模拟 - 现代浏览器（Chrome/Firefox/Edge）直接忽略它
- 写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">不仅冗余，还可能干扰解析顺序 - 坚持用标准的
<meta charset="UTF-8">即可
真正容易被忽略的是：**BOM 和 <meta> 位置冲突时，浏览器优先信任 BOM**。而记事本的「UTF-8-BOM」选项会强制加 BOM，一旦加了，又没删干净，<meta> 就彻底白写了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
