必须紧贴开头、之前且仅写一次，因浏览器仅扫描前1024字节查找该标签，若被注释、脚本或标题阻挡，将回退至系统默认编码（如GBK或ISO-8859-1），导致中文、emoji及JS中文字符串解析错误甚至报错。
meta charset 必须出现在 开头、<title></title> 之前，且只能写一次 —— 这是浏览器解析 HTML 时识别编码的硬性规则，不是建议。
为什么 meta charset 要紧贴
浏览器在读取 HTML 时，只扫描前 1024 字节来查找 meta charset。如果它被注释、空行、<script></script> 或 <title></title> 挡住，就会 fallback 到系统默认编码（Windows 常为 GBK，macOS/Linux 常为 ISO-8859-1），导致中文、emoji、甚至 JS 中的中文字符串直接报错：Uncaught SyntaxError: Invalid or unexpected token。
- 错误写法示例：
<script>console.log('测试')</script><meta charset="UTF-8"> <title>页面</title>→ 浏览器根本看不到 charset - 正确位置：
<meta charset="UTF-8"> <title>页面</title> - VS Code 状态栏右下角显示的编码必须是
UTF-8（不含 BOM），不是UTF-8 with BOM—— 后者会在文件开头插入EF BB BF三个字节，某些旧 WebView 或 Node.js 模板引擎会误判为非法字符
meta charset="UTF-8" 和 meta http-equiv="Content-Type" 的区别
前者是 HTML5 标准写法，简洁、可靠、被所有现代浏览器支持；后者是 HTML4 风格，虽仍能工作，但多出冗余属性，且容易因引号或空格格式问题失效（比如写成 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 中的空格或换行）。
- 不要混用：
<meta charset="UTF-8">和<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">同时存在时，浏览器只认第一个有效的meta charset -
http-equiv写法在 XHTML 中需闭合（<meta ...>），但在 HTML5 中不推荐使用 - 若服务端已通过 HTTP 响应头发送
Content-Type: text/html; charset=utf-8，meta charset仍应保留 —— 它是离线打开、本地双击运行或缓存失效时的最后保障
文件实际编码与声明不一致的典型表现
声明是 UTF-8，但文件实际保存为 GBK，或反过来，这是乱码最常见原因。现象包括：中文显示为方块、问号、乱码符号，JS 报语法错误，CSS 注释里中文变乱码，甚至整个页面渲染中断。
- 验证方法：用 VS Code 右键 → “Reopen with Encoding” → 选
GBK，如果中文立刻正常，说明文件实为 GBK；再选 “Save with Encoding” →UTF-8（确认不勾选 “with BOM”） - 命令行快速检测：
file -i index.html（Linux/macOS）或 PowerShell 中Get-Content index.html -Encoding Byte | Select -First 3—— 若输出239, 187, 191，即含 BOM - Chrome DevTools → Network → 点开 HTML 请求 → Headers → Response Headers 查看
Content-Type字段，确保其charset=utf-8与文件实际编码一致
真正麻烦的从来不是加一行 <meta charset="UTF-8">，而是编辑器保存编码、HTTP 响应头、外部 JS/CSS 文件编码、模板引擎输出编码这四者没对齐 —— 少一个环节，就可能让 charset 声明形同虚设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
