根本原因是file://协议下浏览器不读HTTP响应头，仅依赖文件自身编码、meta charset位置及BOM状态；必须同时验证三者：文件真实编码（非编辑器显示）、meta是否位于<head>开头1024字节内且无前置干扰、BOM是否被清除（UTF-8无BOM为佳）。
本地双击打开 HTML 文件出现中文乱码，根本原因只有一个：浏览器在 file:// 协议下完全不读 HTTP 响应头，只能靠文件自身内容判断编码——而这个判断极易失败。解决它不是“加个 meta 就行”，而是要同时验证三件事：文件真实编码、meta charset 是否生效、有没有 BOM 或空格干扰。
确认文件实际编码是不是 UTF-8（别信编辑器右下角）
VS Code 右下角显示 “UTF-8” 很可能只是猜测，尤其文件曾被 Windows 记事本保存过、从邮件附件拖进来、或用 FTP 二进制模式传过，实际很可能是 GBK。不信就验证：
- VS Code 按
Ctrl+Shift+P→ 输入Reopen with Encoding→ 分别试选GBK和UTF-8，看哪次中文突然正常 - Linux/macOS 终端执行：
file -i yourfile.html，如果输出charset=gbk或charset=us-ascii（实为检测失败），说明不是 UTF-8 - Sublime Text 同样用
File → Reopen with Encoding验证
检查 meta charset="UTF-8" 是否真在起作用
就算写了 <meta charset="UTF-8">，也可能白写——浏览器只扫描 <head> 开头约前 1024 字节找它，任何前置内容都会让它失效：
- 必须是
<head>标签后第一个非空白字符，前面不能有空格、换行、注释（比如<!-- 编码声明 -->）、BOM - 写成
<meta charset="utf8">或<meta charset="UTF8">无效，只有"UTF-8"是标准值，大小写敏感 - 不要混用：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">在 HTML5 中已不推荐，且不解决本地 file:// 问题
排查 BOM 干扰（Windows 用户最常踩的坑）
UTF-8 with BOM（EF BB BF）看似无害，但在 file:// 场景下会直接破坏 meta charset 解析逻辑——浏览器把 BOM 当作不可见字符，导致后续 <meta> 被跳过，最终 fallback 到 Windows 默认的 GBK：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- VS Code 保存时务必选
Save with Encoding → UTF-8（注意不是UTF-8 with BOM） - Notepad++ 选
编码 → 转为 UTF-8 无 BOM 格式 - 验证是否清除成功：
head -c 3 yourfile.html | xxd输出不应含ef bb bf；PowerShell 用Get-Content yourfile.html -Encoding Byte | Select -First 3看前三字节是不是239 187 191
为什么改完还是乱？再盯一眼文件开头
哪怕编码、meta、BOM 全对，只要文件开头存在肉眼不可见的干扰，依然会失败。打开文件用十六进制编辑器（或 xxd -l 16 yourfile.html）看前 16 字节：
- 理想状态：
3c 21 44 4f 43 54 59 50 45... <!DOCTYPE...—— 直接以 ASCII 开头 - 常见陷阱：开头是
ef bb bf（BOM）、3c 21 2d 2d（<!--注释）、甚至一个看不见的0a（换行）都可能导致解析偏移 - 最稳妥写法：
<!DOCTYPE html><html><head><meta charset="UTF-8">必须紧贴在一起，中间零空格、零换行、零注释
本地预览乱码的本质，是剥离了服务器之后，所有编码决策全压在文件自身的字节序列上。任何一处微小偏差（BOM、空格、大小写、位置偏移）都会让浏览器放弃 UTF-8，退回到系统默认编码。调试时别跳步，一行一行看原始字节，比反复刷新页面更有效。
