必须位于开头1024字节内且为首个子节点，否则浏览器fallback至系统默认编码（如windows-1252），导致全盘乱码；bom、注释、空格或http响应头charset冲突均使其失效。
charset 声明位置太靠后，浏览器直接 fallback 到 Latin-1
浏览器解析 HTML 时，只扫描 开头约前 1024 字节来查找 <meta charset>。一旦超过这个范围才出现，它就彻底失效——浏览器立刻退回到系统默认编码（Windows 常为 Windows-1252，macOS/Linux 常为 ISO-8859-1），而不是你写的 UTF-8。
后果不是“部分乱码”，而是从 <title></title> 开始全盘错解：中文标题显示成 ҳ，emoji 变成 ，JS 读取 document.title 拿到的是损坏的字符串，SEO 工具根本抓不到正确标题。
-
<title></title>内容在<meta charset>之前被解析，已按错误编码转成字节，后续再声明也救不回来 - 即使文件本身是 UTF-8 编码，只要声明位置错，浏览器就不知道该用 UTF-8 解析
- VS Code 默认保存为
UTF-8 with BOM时，BOM（EF BB BF）会占掉开头 3 字节，进一步压缩可用空间，加剧风险
charset 被注释、BOM 或空格挡住，等于没写
浏览器的编码嗅探器对 <meta charset> 前的干扰极其敏感。任何出现在它前面的内容——包括 HTML 注释、<script></script> 标签、多余空格、甚至 BOM ——都会让它失效。
常见翻车现场：
- 写成
<!-- SEO meta --><meta charset="UTF-8">：注释算字节数，可能压线超 1024 -
\n <meta charset="UTF-8">：首行缩进空格计入字节，积少成多 - 文件以 BOM 开头，且
<doctype></doctype>前还有其他内容，BOM + DOCTYPE + 注释就轻松突破阈值 - 用
utf-8（小写）、UTF8（缺连字符）等非标准写法，部分校验工具（如html-validate）会直接报错，W3C 不认
HTTP 响应头 charset 和 meta charset 冲突，谁赢？
HTTP 响应头里的 Content-Type: text/html; charset=GBK 优先级高于 <meta charset="UTF-8">。哪怕 HTML 里写对了，只要服务端发错了头，浏览器仍按 GBK 解析——结果就是 UTF-8 文件被当 GBK 打开，每个中文变两个乱码字。
验证方式很简单：
- Chrome DevTools → Network → 点开 HTML 请求 → Headers → Response Headers → 查看
Content-Type - 命令行：
curl -I https://yoursite.com/index.html - Nginx 配置需显式加：
add_header Content-Type "text/html; charset=utf-8";（注意 mime.types 默认不带 charset） - Express 中要用：
res.set('Content-Type', 'text/html; charset=utf-8')，不能只依赖res.send()
charset 写对了但文件实际不是 UTF-8，JS 报错停在第一行
最隐蔽的坑：HTML 文件本身是 GBK 编码，却硬写 <meta charset="UTF-8">。浏览器强行按 UTF-8 解析 GBK 字节流，结果所有中文、标点、甚至 JS 字符串里的引号都变成非法字节序列。
典型现象：
- 控制台报
Uncaught SyntaxError: Invalid or unexpected token，错误定位在 JS 第一行第一个字符 - 页面空白，连
都没渲染出来 - 用
head -c 4 index.html | xxd检查文件开头：若输出含ef bb bf是 UTF-8 with BOM；若为cd a8类似 GBK 双字节，则编码和声明严重不匹配 - Notepad++ 中“编码 → 转为 UTF-8”比“另存为 UTF-8”更可靠，后者可能仅改声明不转内容
实际部署时，<meta charset="UTF-8"> 必须是 的第一个子节点，前面不能有任何字符（包括 BOM、空格、换行、注释）。这看似简单，但在模板引擎拼接、构建工具注入、CDN 缓存污染等场景下，极易被悄悄破坏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
