必须紧贴开头，否则浏览器在解析到等标签前已按默认编码（如iso-8859-1）解码，导致中文乱码且后续声明无效；注释、bom、空格均不可插入其间。
meta charset 必须放在 最前面，否则中文大概率会乱码——不是“可能”，是浏览器解析到第一个非 meta 标签（比如 <title></title>）时，就已按默认编码（通常是 ISO-8859-1）开始解码，后面再声明也无效。
为什么 <meta charset="UTF-8"> 要紧贴
浏览器解析 HTML 是流式、自上而下的。它在遇到第一个 <meta charset> 时才切换内部编码器；如果之前已读到 <title>你好</title>，而此时还在用 ISO-8859-1 解码，那“你好”两个字就会被当成非法字节直接丢弃或替换为 ，后续即使写了 charset="UTF-8" 也救不回来。
- 错误位置示例：
<title>测试页</title> <meta charset="UTF-8">→ 中文标题已乱码 - 正确顺序必须是：
<meta charset="UTF-8"> <title>测试页</title> - 连注释都不能插在中间：
<!-- 注释 --><meta charset="UTF-8">在部分旧 IE 中也可能失效
编辑器保存为 UTF-8 无 BOM 是硬性前提
meta charset 声明只是“告诉浏览器怎么读”，但前提是文件本身确实是 UTF-8 编码。如果用 Notepad++ 或 VS Code 保存时选了 “UTF-8 with BOM”，开头会多出三个不可见字节 EF BB BF，可能导致：
- DOCTYPE 前出现空白，触发 quirks mode（怪异模式）
- CSS 中
@charset规则识别失败 - JS 文件头部报
Unexpected token错误
VS Code 右下角显示 “UTF-8” 即可；若显示 “UTF-8 with BOM”，点它 → “Save with Encoding” → 选 “UTF-8”。Notepad++ 同理：编码 → 转为 UTF-8 无 BOM 格式。
服务端响应头 Content-Type 优先级高于 meta
HTTP 响应头里的 Content-Type: text/html; charset=gbk 会直接覆盖 HTML 内的 meta charset。哪怕你写对了所有前端细节，只要服务器发错头，页面照样乱码。
- Nginx 配置需加：
charset utf-8;（在http、server或location块中） - Apache 用
.htaccess：AddDefaultCharset UTF-8 - PHP 动态页必须在
echo任何内容前调用：header('Content-Type: text/html; charset=utf-8'); - 检查方式：浏览器开发者工具 → Network → 点开 HTML 请求 → Response Headers → 找
Content-Type
CSS 和 JS 外部文件也要独立保证 UTF-8
HTML 的 meta charset **只作用于 HTML 本身**，不影响 <link rel="stylesheet"> 或 <script src></script> 加载的外部资源。如果 style.css 用 GBK 保存，里面写 content: "按钮";，那 CSS 中文照样变 。
- VS Code 打开 CSS/JS 文件 → 右下角确认是 “UTF-8” → 若不是，点它 → “Reopen with Encoding” → 选 UTF-8 → 再 “Save with Encoding” → 选 UTF-8
- Webpack/Vite 构建时，raw-loader 等若未显式指定
encoding: 'utf8'，读取中文路径或内容可能退化为 latin1 - Node.js
fs.readFileSync(path, 'utf8')的'utf8'参数不能省，否则返回 Buffer，易被误当二进制处理
最容易被忽略的是：HTML 正确、编辑器正确、服务端响应头也正确，但乱码仍出现在某段动态插入的内容里——那八成是后端模板（如 EJS、Twig）输出前没转义或没设好输出编码，或者前端 JS 拼接字符串时混入了非 UTF-8 来源的数据（比如从 legacy API 拿到的 GBK 编码响应体）。这时候得一层层查数据流源头，而不是反复改 meta 标签。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
