必须紧贴开头、前面不能有任何字符（含BOM、空格、注释、等），否则浏览器仅扫描前1024字节即中断识别，fallback至系统默认编码（Windows为GBK，Linux/macOS为ISO-8859-1），导致中文显示为方块或问号。
meta charset 必须放在 开头且不能有前置内容，否则在多数浏览器中直接失效——这是中文乱码最常被忽略的硬性限制。
为什么 meta charset="UTF-8" 放错位置就失效
浏览器解析 HTML 时，只扫描前 1024 字节找 meta charset；一旦遇到 BOM（EF BB BF）、注释（）、空行、<script></script> 或
- 错误写法：
→ 注释导致失效 - 错误写法：
<script></script>→<script></script>阻断识别 - 正确写法：
（紧贴，无换行、无空格、无注释）
如何验证文件实际编码是否为 UTF-8（不含 BOM）
VS Code 显示 “UTF-8 with BOM” 就是隐患：BOM 会卡在 前面，让 meta charset 失效。必须手动转成纯 UTF-8。
- Linux/macOS：用
head -c 4 index.html | xxd，输出含ef bb bf就是带 BOM - PowerShell：用
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239, 187, 191就是 BOM - VS Code 修复：Ctrl+Shift+P → “Change File Encoding” → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM）
本地双击打开（file://）时乱码怎么办
HTTP 响应头完全缺失，meta charset 是唯一依据；但若文件本身不是 UTF-8 编码，或 meta 失效，浏览器只能按系统默认编码读取——Windows 默认 GBK，必然乱码。
- 绝对不要双击 HTML 文件测试中文显示
- 必须用本地服务器：VS Code 安装 Live Server 插件，右键 “Open with Live Server”，地址变成
http://127.0.0.1:5500/ - 此时 HTTP 响应头生效，
Content-Type: text/html; charset=UTF-8优先级高于meta，双重保障
服务端配置补漏（Nginx / Apache / Express）
即使前端 meta 和文件编码都对，服务端没设 charset，HTTP 响应头可能不带 charset=UTF-8，某些环境（如旧版 IE 或代理）仍会 fallback。
- Nginx：在
server或location块加charset utf-8;（不是add_header Content-Type） - Apache：在站点目录放
.htaccess，写AddDefaultCharset UTF-8 - Express：响应前加
res.set('Content-Type', 'text/html; charset=UTF-8')，或统一用res.send()（它默认带 charset）
真正卡住中文显示的，从来不是“要不要加 meta charset”，而是它有没有被浏览器真正读到——位置、BOM、传输协议、服务端头，四者缺一不可。尤其 file:// 场景下，光靠 meta 是靠不住的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
