必须置于 最前面，否则旧版浏览器可能因提前按默认编码解析而乱码；应使用 而非 http-equiv 版本，并确保文件实际保存为 UTF-8 无 bom 格式。
html5 中
浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、日文），会立即用当前已知的编码去解码。如果 写在
正确做法是：把 作为 的第一个子元素，紧贴 开始标签之后：
页面标题 ... - 不能写成
—— 这是 HTML4 的兼容写法，html5 明确不推荐 - 不能省略引号：
charset=UTF-8虽然多数浏览器能识别，但不符合 HTML5 规范，W3C 验证器会报错 - 值必须是真实支持的编码名，
"utf-8"（小写）和"UTF-8"（大写）都合法，但建议统一用大写，避免某些老旧工具误判
服务器响应头 Content-Type 和
当 HTTP 响应头中包含 Content-Type: text/html; charset=GBK，而 HTML 里又写了 ，浏览器行为不一致：
- chrome / firefox / safari：优先采用响应头中的编码，
被忽略（除非响应头未声明 charset） - edge（旧版）/ 某些 android WebView：可能尝试按
切换，造成渲染中断或乱码
所以最稳妥的方式是：让服务器响应头和 HTML 中的声明严格一致。例如用 nginx 配置：
立即学习“前端免费学习笔记（深入）”；
charset utf-8;或在 php 中输出前加：
header('Content-Type: text/html; charset=utf-8');若无法控制服务器（如静态托管到 gitHub Pages、Vercel），就只能依赖 ，此时务必确认文件本身确实保存为 UTF-8 无 BOM 格式 —— 编辑器选错格式是常见乱码根源。
为什么不用
这个写法在 HTML4 时代模拟 HTTP 头，HTML5 已将其降级为“向后兼容机制”，规范明确指出： 更简洁、解析更快、且被所有现代浏览器优先支持。
-
实际上要等浏览器解析到该标签并提取content属性，比直接读charset属性多一步解析逻辑 - 部分精简解析器（如某些邮件客户端内嵌引擎）完全忽略
http-equiv，只认charset - W3C Validator 会对
http-equiv版本标为 “Warning: Consider using the charset Attribute instead.”
编辑器保存格式不匹配会导致
即使写了 ，如果 HTML 文件实际是以 GBK 或 UTF-8 with BOM 方式保存的，浏览器仍会按字节流错误解码 —— 尤其是 windows 记事本默认保存为 ANSI（即系统 locale 编码），一存中文就埋雷。
- VS Code：右下角点击编码名称 → 选择 “Save with Encoding” → 选 “UTF-8”（不是 “UTF-8 with BOM”）
- sublime Text：File → Save with Encoding → UTF-8
- 确认方式：用命令行
file -i filename.html（linux/macos）或xxd -l 12 filename.html查看前几个字节，UTF-8 无 BOM 不应有ef bb bf
真正起作用的从来不是那行 meta 标签，而是它所声明的编码与文件字节流、传输通道、渲染引擎三者是否对齐。少一个环节，乱码就来了。