必须紧接开头、早于等任何标签，且唯一；浏览器仅扫描前1024字节查找它，失效则fallback至系统默认编码导致乱码、emoji异常及js语法错误。
meta charset 必须放在 head 最前面，且只能有一个
浏览器解析 HTML 时，只读取前 1024 字节来查找 <meta charset>；如果它被 <title></title>、<script></script> 或注释挡在后面，就可能失效。一旦错过，浏览器会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），导致中文乱码、emoji 显示为 、JS 报 Uncaught SyntaxError: Invalid or unexpected token。
-
<meta charset="UTF-8">必须紧接在开始之后，且早于<title></title>、任何<script></script>、<style></style>或注释 - 同一页面中不能出现两个
<meta charset>；若同时写了<meta charset="UTF-8">和<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，后者会被忽略 - 文件本身必须真实保存为 UTF-8 编码（推荐带 BOM，尤其在 Windows 环境下；Notepad++ 中选“转为 UTF-8-BOM”）
charset 值必须严格写成 "UTF-8"，大小写和拼写都不能错
HTML5 规范只接受全大写加连字符的 UTF-8。写成 utf-8、UTF8 或 utf8 虽然多数浏览器能容错识别，但 W3C 验证器和 CI 工具（如 html-validate）会直接报错。
- ✅ 正确：
<meta charset="UTF-8"> - ❌ 错误：
<meta charset="utf-8">（小写）、<meta charset="UTF8">（缺连字符）、<meta charset="utf8">（大小写+缺连字符） - ⚠️ 注意：不要混用旧式写法
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 它在 HTML5 中已过时，仅用于兼容极老 IE
HTTP 响应头比 meta charset 优先级更高
如果服务器返回的 HTTP 响应头里有 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了 <meta charset="UTF-8">，浏览器也会按响应头编码解析，最终还是 GBK 解码 → 乱码。
- 检查方式：浏览器 DevTools 的 Network 标签页，点开 HTML 请求，看 Response Headers 中的
Content-Type - 修复路径：改服务器配置（如 Nginx 的
charset utf-8;）、静态托管平台设置、或构建工具（Vite/Webpack）输出 HTML 时确保不覆盖 charset - 本地开发时常见陷阱：用 file:// 协议打开 HTML 文件 → 没有 HTTP 头 → 此时才真正依赖
<meta charset>
charset 失效时的典型现象和快速自查项
不是所有乱码都源于 charset 错误，但以下现象基本可以锁定问题根源：
- 中文显示为方框 或一堆问号（如 ），尤其是
<title></title>里也乱码 - DevTools 的 Encoding 菜单显示为
ISO-8859-1或Windows-1252，而非UTF-8 - JS 中含中文字符串时报错
Invalid or unexpected token，且错误位置指向第一行中文字符 - Emoji 显示为空白或豆腐块，但纯 ASCII 文本正常
查完 <meta charset> 位置、拼写、文件编码、HTTP 头四者，99% 的字符集问题就定位完了。剩下那 1%，往往是构建流程里模板引擎二次渲染时删掉了 charset，或者 CDN 缓存了旧版 HTML —— 这时候得盯住生成环节，而不是反复改标签。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
