根本原因是file://协议下浏览器仅扫描前1024字节识别<meta charset="UTF-8">，若文件开头含BOM、空行、注释或该标签位置错误，即fallback至系统默认编码（如GBK），导致中文显示为方块或问号；必须确保文件为无BOM的UTF-8编码、<meta charset="UTF-8">紧贴<head>开头且无前置字符，并用xxd或file -i验证真实编码。
本地直接双击打开 HTML 文件（file:// 协议）时，浏览器不读 HTTP 响应头，meta charset 是唯一生效的编码声明方式——但它的位置、格式、文件实际编码三者必须严丝合缝，缺一不可。
为什么双击打开总显示乱码？
根本原因是：浏览器在 file:// 下只靠前 1024 字节内能否快速识别 <meta charset="UTF-8"> 来决定解码方式。一旦文件开头有 BOM、注释、空行或 <meta> 写错位置，就直接 fallback 到系统默认编码（如 Windows 的 GBK），中文立刻变方块或问号。
-
<meta charset="UTF-8">必须是<head>内第一个标签（紧贴<head>开始，前面不能有任何空格、换行、注释或<script>） - 文件保存时必须选
UTF-8，**不能选UTF-8 with BOM**；VS Code 默认可能带 BOM，保存前务必确认编码选项 - 用
xxd -l 3 index.html（Linux/macOS）或十六进制编辑器检查文件头：若出现ef bb bf，说明有 BOM，需重存为无 BOM 的 UTF-8
VS Code 保存为无 BOM 的 UTF-8 怎么操作？
右下角状态栏点击当前编码（如 “UTF-8 with BOM” 或 “GBK”），选择 Save with Encoding → 点击 UTF-8（注意不是 “UTF-8 with BOM”）。保存后刷新页面，乱码通常立即消失。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 如果状态栏没显示编码，先用快捷键
Ctrl+Shift+P（Win）或Cmd+Shift+P（Mac）打开命令面板，搜 “Change File Encoding”，再选UTF-8 - 改完后用终端执行
file -i index.html验证：输出中应含charset=utf-8，而非charset=unknown或charset=gbk - 别依赖自动检测——VS Code 有时会把 GBK 文件误标为 UTF-8，导致你“以为”改对了，实则文件内容仍是 GBK 字节
测试页里怎么快速验证编码是否生效？
在页面 body 里加一行测试代码：<p>测试：你好，世界！</p>。如果显示正常，说明编码链路通了；如果显示为 ã 或 æµ‹è¯•ï¼šä½ å¥½ï¼Œä¸–ç•Œï¼Œ，说明文件实际字节和声明不匹配。
立即学习“前端免费学习笔记（深入）”；
- Chrome/Firefox 开发者工具（F12）→ Console 输入
document.characterSet，返回值必须是"UTF-8"才算成功 - 不要只看页面渲染结果——有些浏览器会“猜错后强行修复”，看似正常，但复制粘贴或 AJAX 提交时仍会出错
- 避免用中文标点写注释（如
<!-- 测试 -->）放在<meta>前，某些旧版浏览器会因此跳过 meta 解析
真正卡住人的地方，往往不是 meta 标签本身，而是编辑器悄悄塞进去的 BOM、文件保存时选错编码、或者开发工具里看到的“UTF-8”只是编辑器的误判——得用十六进制或 file -i 这类底层命令交叉验证，才能断定字节流到底是什么。
