必须置于最开头且文件实际为utf-8无bom编码，因浏览器仅扫描前1024字节识别该标签，若遇中文、bom、注释或等非ascii内容前置，即fallback至系统默认编码（如windows的gbk）导致乱码。
meta charset="UTF-8" 必须放在 最开头，且文件本身必须是 UTF-8（无 BOM）编码，否则浏览器不会按此解析——这不是“设置默认打开方式”，而是告诉浏览器“这个文件实际用什么编码存的”。
为什么 meta charset 放错位置就失效
浏览器解析 HTML 时只扫描前 1024 字节，一旦遇到非 ASCII 字符（比如中文 <title>你好</title>、BOM、注释或 <script></script>），又没在前面看到 <meta charset="UTF-8">，就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），直接乱码。
-
<title>你好</title> <meta charset="UTF-8">→ 失效：title 里的中文已触发 fallback -
<meta charset="UTF-8"> <title>你好</title>→ 有效：charset 声明在任何内容之前 - 开头有 BOM（
EF BB BF）或注释<!-- 注释 -->→ meta 被挤到第 4 字节之后，部分旧浏览器（如 IE）可能忽略
怎么验证文件实际编码是不是 UTF-8
编辑器保存时选错编码，比写错 meta 标签更常见。不能只看“看起来正常”，要查真实字节：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- VS Code：右下角点击编码名称 → 选 Reopen with Encoding → 试 GBK/ISO-8859-1，如果中文变乱码，说明当前是 UTF-8；再点 Save with Encoding → 选
UTF-8（**不勾选 “with BOM”**） - 命令行（Linux/macOS）：
xxd -l 4 index.html，输出ef bb bf表示带 BOM，应避免 - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若输出239 187 191就是 BOM
HTTP 响应头和 meta 冲突怎么办
当通过 http:// 或 https:// 访问时，服务器返回的 Content-Type: text/html; charset=xxx 优先级高于 meta。本地双击打开（file://）才完全依赖 meta。
- Nginx 配置要写
charset utf-8;（小写，无等号，无引号） - Apache 的
.htaccess用AddDefaultCharset UTF-8（大小写敏感，不能写成utf8） - Express.js 中用
res.set('Content-Type', 'text/html; charset=utf-8')，不是res.header()或res.contentType() - 用浏览器 DevTools 的 Network → Response Headers 看实际返回值，别信 Preview 里的渲染效果
charset 值哪些写法是错的
只有 "UTF-8" 是 HTML5 规范认可的合法值。其他看似相近的写法都会在某些环境出问题：
-
charset="utf8"：缺短横线，Safari 和旧 Edge 可能无视 -
charset="UTF8"：缺短横线 + 缺数字 8 的独立性，IE 直接失败 -
charset="utf-8"：小写 u，虽 Chrome/Firefox 容错，但不符合规范，CDN 或代理可能重写 -
charset="unicode"：完全无效，没有任何浏览器识别 -
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">：冗余、易出错，HTML5 已不推荐
最常被忽略的一点：即使 meta 写对了、HTTP 头也配对了，只要源文件保存时用了 GBK 编码，浏览器就会用 UTF-8 去解 GBK 字节——结果全是问号或方块。编码声明和文件实际字节，必须严格一致。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
