根本原因是浏览器在file://协议下未读到UTF-8声明而fallback至GBK；因只扫描前1024字节，BOM/注释/空行或文件实际为GBK编码均会导致<meta charset="UTF-8">失效，必须确保文件存为无BOM的UTF-8且该标签紧贴<head>开头。
离线打开 HTML 文件时中文变乱码，根本原因只有一个：浏览器没读到 UTF-8 编码声明， fallback 到了系统默认编码（Windows 是 GBK）。
为什么 <meta charset="UTF-8"> 在 file:// 下有时失效
浏览器对 file:// 协议的处理很保守——它只扫描 HTML 文件前 1024 字节找 <meta charset>，一旦开头有 BOM、注释、空行或不可见字符（比如 UTF-8 with BOM 的 EF BB BF），就可能跳过识别。更糟的是，如果文件本身存为 GBK 或 ANSI，哪怕写了 <meta charset="UTF-8">，浏览器也会先用 GBK 解码，把 UTF-8 字节流错解成乱码，再渲染时已无力回天。
- 用
head -c 4 index.html | xxd（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell）检查开头是否含EF BB BF - VS Code 状态栏显示 “UTF-8 with BOM” 就要警惕，点右下角编码 → “Save with Encoding” → 选 “UTF-8”（不含 BOM）
-
<meta charset="utf8">或<meta charset="UTF8">写法错误，必须是"UTF-8"（带连字符） - 该标签必须紧贴
<head>开始，前面不能有任何字符（包括空格、换行、<!-- comment -->）
怎么验证当前文件编码和 meta 是否生效
离线场景没法看 HTTP 响应头，只能靠“双重确认”：
- 在 VS Code / Sublime Text 中打开文件，确认右下角显示 “UTF-8”（不是 “UTF-8 with BOM” 或 “GBK”）
- 用浏览器（Chrome/Firefox）打开文件，按
F12→ Network → 刷新 → 点 HTML 请求 → Headers → 查看 “Response Headers” 里有没有Content-Type；file://下这里一定是空的，所以全靠<meta>生效 - 手动在地址栏输入
view-source:file:///path/to/index.html，确认源码里中文是正常汉字，不是ä¸æ–‡这类拉丁乱码 —— 如果源码已乱，说明文件保存编码错了，改编码重存
离线环境最稳的三步操作
不依赖服务器、不改系统设置、不装插件，纯前端可控：
立即学习“前端免费学习笔记（深入）”；
- 用 VS Code 打开 HTML 文件 → 右下角点击当前编码 → “Save with Encoding” → 选
UTF-8（明确不含 BOM） - 删掉
<head>前所有内容（包括空行、注释、BOM），确保第一行就是<!DOCTYPE html>或<html>，第二行是<head>，第三行是<meta charset="UTF-8"> - 避免用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 它在离线模式下兼容性差，且容易被忽略
真正麻烦的不是写错标签，而是文件编码和 meta 声明不一致。很多人改了 <meta> 却没重存文件，或者重存时选了带 BOM 的 UTF-8，结果白调半天。离线场景下，编码和声明必须咬死对齐，缺一不可。
