只靠不够，必须同时确保html文件本身为utf-8无bom编码，且该标签严格位于开头、任何注释/空格/bom之前；浏览器仅扫描前1024字节，若前面存在bom、注释或空格，将fallback至系统默认编码（如windows的gbk）导致乱码。
直接结论：只靠 <meta charset="UTF-8"> 不够，必须同时确保 HTML 文件本身是 UTF-8 编码（无 BOM 更稳妥），且该标签严格位于 开头、任何注释/空格/BOM 之前。
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器只扫描 HTML 文件前 1024 字节找这个标签，而且必须在第一个非空白、非注释、非 BOM 字节之后立即出现。一旦前面有：
-
EF BB BF（UTF-8 BOM）—— 浏览器可能 fallback 到系统默认编码（Windows 是 GBK） -
<!-- 注释 -->或换行/空格 —— 扫描跳过，直接用 ISO-8859-1 解析 -
<script></script>或<title></title>标签 —— 已超出有效扫描范围
结果就是：源码里明明写了 UTF-8，页面却显示成 。
如何验证 HTML 文件真实编码是否为 UTF-8
别信编辑器右下角显示的“UTF-8”——它只表示当前打开方式，不等于文件实际存储格式。必须查字节：
- Linux/macOS：
file -i index.html→ 输出含charset=utf-8才算实锤 - Linux/macOS：
xxd -l 3 index.html→ 若开头是ef bb bf，说明带 BOM；若乱码或显示00 00 00，大概率是 GBK 存的 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3→ 看前 3 字节是否为239 187 191 - VS Code：先
Reopen with Encoding选GBK，如果中文正常了，证明文件其实是 GBK 编码
HTTP 响应头和 <meta charset> 谁优先？
当通过 http:// 或 https:// 访问时，服务器返回的 Content-Type 响应头（如 text/html; charset=utf-8）优先级高于 <meta charset>。但注意：
- Nginx 默认不发 charset，需手动加
charset utf-8;（小写，不能写 UTF-8） - Apache 需在
.htaccess或配置中加AddDefaultCharset UTF-8 - Express 中
res.sendFile()不自动设 charset，必须显式调用res.set('Content-Type', 'text/html; charset=utf-8') - 用
file://双击打开 HTML？那响应头不存在，<meta charset>是唯一救命稻草，位置容错率为零
最简安全写法（推荐直接复制）
把下面这段作为 HTML 的绝对开头，不要空行、不要注释、不要 BOM：
<meta charset="UTF-8"><title>我的页面</title>
然后立刻检查三件事：
- 保存时选 “UTF-8 without BOM”（Notepad++ / VS Code 都有此选项）
- 用
file -i或 PowerShell 验证字节，确认无ef bb bf - 打开 DevTools → Network → 刷新 → 点 HTML 请求 → 查 Response Headers 中
Content-Type是否含charset=utf-8
这三步缺一不可。很多人卡在第一步：以为保存为 UTF-8 就万事大吉，其实编辑器悄悄加了 BOM，而 BOM 正是让 <meta charset> 失效的元凶。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
