必须置于最开头，因浏览器流式解析html，若此前已用错误编码（如gbk或iso-8859-1）解码了或等内容，后续即使声明utf-8也无法挽回乱码、脚本错误等问题。
meta charset 必须写在 最开头，且文件本身必须是 UTF-8 编码（无 BOM），否则浏览器会按错误编码解析后续内容，直接导致乱码、alert 报错、console.log 显示、CSS/JS 中文注释失效等——这不是“没生效”，而是浏览器根本没机会读到那行 meta。
为什么 meta charset 一定要放在
浏览器解析 HTML 是流式逐字节读取的。在遇到 meta charset 之前，它只能依赖 HTTP 响应头或系统默认编码（如 Windows 上常为 GBK）来解码已读内容。一旦用错编码解码了前几十个字节，<title></title> 里的中文、内联 <script></script> 的字符串、甚至 <link rel="stylesheet"> 的 href 路径都可能被破坏，后续即使出现 meta charset="UTF-8" 也无力回天。
-
<title>你好</title> <meta charset="UTF-8">❌：标题里“你好”已被按 ISO-8859-1 或 GBK 错误解码，显示为乱码 -
<meta charset="UTF-8"> <title>你好</title>✅：浏览器从第一个字节起就用 UTF-8 解码 - 注释、空格、BOM 都算“前面”。
<!-- 注释 --><meta charset="UTF-8">也不行
怎样验证 meta charset 真正起效了？
不能只看 HTML 源码里有没有那行。要三处一致：
- 浏览器 DevTools → Network → 点开 HTML 请求 → Response Headers 里的
Content-Type字段（例如text/html; charset=UTF-8） - 同个请求的 Preview 或 Response 标签页里，中文是否正常显示（不是 或小方块）
- 控制台执行
document.characterSet或document.inputEncoding，返回值应为"UTF-8"
三者不一致时，以 Response Headers 为准——服务器响应头优先级高于 meta；若用 file:// 协议打开本地文件，则完全依赖 meta，此时 HTTP 头为空，meta 就是唯一依据。
编辑器保存编码和 meta charset 值必须严格匹配
meta charset="UTF-8" 是告诉浏览器“请用 UTF-8 解我”，但如果文件实际是 GBK 编码保存的，浏览器就会用 UTF-8 去解 GBK 字节流，结果必然是乱码。常见陷阱：
- VS Code 新建文件默认 UTF-8，但打开一个旧 GBK 文件后，保存时若没手动选 “Save with Encoding → UTF-8”，仍会存为 GBK
- Windows 记事本保存时选 “UTF-8” 默认带 BOM，而
meta charset在含 BOM 的文件中可能被 IE 等老浏览器忽略（BOM 占前 3 字节，<meta> 不再是文件开头） -
charset的值必须写成"UTF-8"（大写 UTF，短横，数字 8），不能写"utf8"、"utf_8"、"unicode"—— 这些非标准写法在部分环境会 fallback 到默认编码
服务端配置比 meta 更底层，但别盲目覆盖
Apache 用 AddDefaultCharset UTF-8，Nginx 写 charset utf-8;，Node.js Express 调用 res.set('Content-Type', 'text/html; charset=UTF-8')，都能在响应头注入正确的 Content-Type。但这不意味着可以删掉 meta charset：
- 静态文件托管平台（如 GitHub Pages、Vercel）通常默认设好响应头，但本地
file://测试时完全无效 - 某些代理或 CDN 可能剥离或改写响应头，
meta是最后一道防线 - 如果服务端设了
charset=GBK，而 HTML 里写UTF-8，浏览器会以响应头为准，meta形同虚设——此时必须统一服务端配置，不能靠前端硬扛
真正容易被忽略的是：外部资源（CSS、JS、字体文件）的编码也要同步检查。哪怕 HTML 完美，一个 GBK 编码的 style.css 里写了 content: "箭头";，照样会显示异常。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
