必须紧贴开头，是浏览器解析机制决定的硬性要求；若位置错误，会导致中文乱码、异常、内联脚本执行失败。
meta charset 必须紧贴 或 开头写，不是“最好”，而是浏览器解析机制决定的硬性要求；放错位置，中文直接变乱码、<title></title> 显示异常、甚至内联脚本执行失败。
为什么浏览器会因位置错乱而解码失败
浏览器加载 HTML 时，不会等全部内容下载完才开始解析——它边收数据边扫描，且只在前 1024 字节内查找 <meta charset>。如果前面有 <title>你好</title> 或注释、空格、BOM，而此时还没看到 <meta charset="UTF-8">，浏览器就默认用 ISO-8859-1 或系统编码（如 Windows 上的 GBK）去解码已读入的字节。
一旦“你好”两个汉字被错解成 4 个 Latin-1 字符，DOM 已损坏，后续无论怎么补 <meta> 都无法回退修复。
- 旧版 IE 可能完全忽略非首位置的
<meta charset> - 即使服务器返回了
Content-Type: text/html; charset=UTF-8，HTML 内的<meta charset>仍需尽早声明，以防响应头延迟或缺失 - BOM（
ef bb bf）虽不占标签位置，但规范建议<meta charset>紧跟其后，逻辑上仍是“最先生效的编码声明”
实际写法中哪些细节会导致失效
看似简单的一行，踩坑点极多：
- 写成
<meta charset="utf8">或<meta charset="utf-8">：只有UTF-8（全大写、带短横）是标准值，其他形式部分浏览器会 fallback 到默认编码 - 放在
<title></title>或<script></script>后面：哪怕只差一行，也大概率超出“前 1024 字节探测窗口” - 文件本身带 UTF-8 BOM 但编辑器没显示：VS Code 默认保存为 “UTF-8 with BOM”，导致 HTML 开头实际是不可见的
ef bb bf，再加空行或注释，<meta>就掉出安全区 - 同时写了
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">：HTML5 中已废弃，冗余且可能干扰解析顺序
如何验证是否真正生效
不能只看页面显示正常——要查三层：
- 用
head -c 3 index.html | xxd检查开头是否含ef bb bf（BOM），若有，确认<meta charset="UTF-8">是 BOM 后第一个标签 - 打开浏览器 DevTools → Network → 点开 HTML 请求 → 查看 Response Headers 中
Content-Type是否含charset=UTF-8，若为gbk等，<meta>会被强制覆盖 - 用
file -i index.html确认文件真实编码，必须与<meta charset>值一致；GBK 文件写UTF-8，必然乱码
最稳妥的做法：删掉所有注释和空行，让 <meta charset="UTF-8"> 成为 内第一个可见标签，且文件保存为 “UTF-8 without BOM”。BOM 和响应头冲突、编辑器编码设置错位、服务端配置遗漏——这些才是乱码反复出现的真正根源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
