http响应头缺失时，是fallback机制，但仅在http/https协议下生效；file://协议下完全失效，且要求其必须位于html前1024字节内、无bom/中文/注释阻断、声明值为iana标准utf-8、文件实际编码与声明一致。
Content-Type 响应头缺失时，<meta charset> 是唯一可用的 fallback 机制，但它只在页面通过 http:// 或 https:// 协议加载时生效；用 file:/// 打开会直接失效。
为什么 <meta charset="UTF-8"> 在响应头缺失时仍可能失效
浏览器解析 HTML 时，前 1024 字节内必须能扫描到有效的 <meta charset>，且不能被非 ASCII 字符（如中文 <title>标题</title>、BOM、注释、emoji）阻断。一旦开头出现中文或 BOM，IE/旧 WebView 可能跳过识别，回退到系统默认编码（Windows 是 GBK）。
-
<title>首页</title> <meta charset="UTF-8">→ 失效：title 内容已超 ASCII 范围 -
<!-- 注释 --><meta charset="UTF-8">→ 失效：注释含非 ASCII 字符或长度超限 -
<meta charset="utf8">→ 失效：“utf8” 不是 IANA 注册值，部分 WebView 拒绝识别 - 文件实际保存为 GBK，但写了
<meta charset="UTF-8">→ 必乱：字节流和声明完全错配
确保 <meta charset> 被识别的实操要点
不是写上就行，要让它“被看见”。关键动作都在编辑器和文件保存环节：
- VS Code：右下角点击编码显示（如 “GBK”），选 Reopen with Encoding → UTF-8，再选 Save with Encoding → UTF-8 with BOM
- Notepad++：编码 → 转为 UTF-8-BOM，再另存为（不要选“转为 ANSI”后再改 meta）
- Sublime Text：File → Save with Encoding → UTF-8
-
<meta charset="UTF-8">必须是内第一个标签，前面不能有任何字符（包括空格、换行、BOM 以外的不可见符）
验证是否真起作用，别信编辑器显示
编辑器说“UTF-8”不等于浏览器按 UTF-8 解析。真实链路是：文件字节 → HTTP 响应头 → <meta> → 渲染。响应头缺失时，后两者才参与竞争。
- Chrome DevTools → Network → 刷新 → 点击 HTML 请求 → 查看 Response Headers 是否有
Content-Type: text/html; charset=utf-8；若无，再看 Response 标签页里开头是否干净显示<meta charset="UTF-8"> - 命令行快速验证文件编码：
file -i index.html（macOS/Linux）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell），确认前三字节是239, 187, 191（EF BB BF） - 如果页面仍乱码，打开开发者工具 Console，看是否有
Uncaught SyntaxError: Invalid or unexpected token—— 这往往意味着 JS 文件或内联脚本因编码错位被截断，根源还是 HTML 文件本身没存对
真正卡住人的从来不是怎么写 <meta charset>，而是改完文件编码后忘了检查它是否还“在开头 1024 字节里活着”。BOM、注释、title 文字、甚至编辑器自动插入的 license header，都可能把它挤出识别窗口。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
