必须置于开头、之前，且前方不能有任何字符（含bom、空格、换行、注释），否则浏览器在前1024字节内无法识别，将回退至系统默认编码（windows为gbk，macos/linux为iso-8859-1），导致中文乱码、emoji异常及js语法错误。
meta charset 必须放在 开头、<title></title> 之前，且前方不能有任何字符（包括 BOM、空格、换行、注释），否则浏览器在前 1024 字节内找不到它，就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），直接导致中文乱码。
为什么 meta charset="UTF-8" 放错位置就失效
浏览器解析 HTML 时，会在读取前 1024 字节时主动扫描 meta charset 声明。一旦错过这个窗口：
- 前面有 BOM（
ef bb bf）——VS Code 默认保存为 “UTF-8 with BOM” 就会触发 - 开头有空格或换行（哪怕
\n <meta charset="UTF-8">中的换行后缩进也算） - 有 HTML 注释（
<!-- 页面配置 --><meta charset="UTF-8">） - 前面插入了
<script></script>或<style></style>（哪怕只是空标签）
都会让声明被跳过，浏览器立刻用 GBK 解析 UTF-8 字节流，结果就是 。
怎么验证文件实际编码和 BOM 是否合规
别信编辑器右下角显示的“UTF-8”，要实测字节：
- Linux/macOS：
head -c 4 index.html | xxd，输出含ef bb bf就有 BOM，必须清除 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239, 187, 191就是 BOM - VS Code：点击右下角编码 → “Save with Encoding” → 选
UTF-8（**不是** “UTF-8 with BOM”） - Notepad++：菜单栏“编码” → “转为 UTF-8 编码”（**不是** “UTF-8-BOM”）
HTTP 响应头里的 Content-Type 比 meta 更优先
当页面通过 HTTP 加载（http:// 或 https://），服务器返回的响应头中 Content-Type: text/html; charset=utf-8 会直接覆盖 HTML 内的 meta 声明。常见坑点：
- Nginx 配置漏写
charset utf-8;（需放在server或location块里） - Express 中
res.set('Content-Type', 'text/html; charset=utf-8')忘加，或写成UTF8/utf8（必须小写utf-8） - PHP 中
header("Content-Type: text/html; charset=utf-8")前有输出（哪怕一个空格或 BOM）会导致 header 失效 - 静态托管（如 GitHub Pages、Vercel）默认发
utf-8，但若你上传的是 GBK 文件，声明再对也白搭
真正卡住人的从来不是“要不要写 meta charset”，而是文件存的编码、BOM 存在与否、HTTP 响应头三者是否咬死一致。少一个环节，乱码就从源头开始。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
