必须置于最开头，且文件真实编码、http响应头charset、html内声明三者必须均为utf-8，缺一不可。
meta charset必须放在head最开头
浏览器一解析到 就开始读取内容，一旦遇到第一个 <meta charset> 就立刻切换编码；如果前面有 <title></title>、<script></script> 或注释，它可能已经用默认编码（比如 ISO-8859-1）把中文标题或脚本内容错解一遍，再切也救不回来。
常见错误现象：<meta charset="UTF-8"> 放在 <title></title> 后面，页面标题显示为乱码或问号；或者整个 <meta> 被写成自闭合形式 <meta charset="UTF-8">，部分旧版 IE 不识别。
- 正确写法：
<meta charset="UTF-8"> <title>...</title>，紧贴开始标签 - 不要用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，冗余且易拼错 - 如果用了
<meta name="viewport">，它必须排在<meta charset>后面
HTTP响应头里的charset优先级更高
即使 <meta charset="UTF-8"> 写对了，只要服务器返回的 HTTP 响应头里是 Content-Type: text/html; charset=GBK，浏览器就按 GBK 解析——<meta> 直接被忽略。
检查方式：打开浏览器开发者工具 → Network → 点 HTML 请求 → 查看 Response Headers 中的 Content-Type 字段。
- Nginx 配置需加
charset utf-8;（注意不是charset GBK;） - PHP 输出前加
header('Content-Type: text/html; charset=UTF-8'); - Node.js（Express）用
res.set('Content-Type', 'text/html; charset=UTF-8'); - 静态托管平台（如 GitHub Pages、Vercel）通常默认发 UTF-8，但若上传时文件本身不是 UTF-8，仍会乱码
编辑器保存编码必须是 UTF-8 无 BOM
VS Code 右下角显示 “UTF-8” 并不等于文件真是 UTF-8 编码——它可能只是“以 UTF-8 重新打开”，而原始文件仍是 GBK。带 BOM 的 UTF-8（即 UTF-8-BOM）会在文件开头插入不可见字节 EF BB BF，导致 前出现空白，某些浏览器会因此忽略 <code><meta charset>。
- VS Code：用
File → Save with Encoding → UTF-8（别选 UTF-8 with BOM） - Sublime Text：用
File → Save with Encoding → UTF-8 - 验证是否带 BOM：
xxd yourfile.html | head，输出首行含ef bb bf就是带 BOM - Windows 记事本保存时，“另存为”编码选“UTF-8”，**不能选“UTF-8-BOM”或“ANSI”**
doctype必须是HTML5标准写法
如果文档开头是 ..> 这类老式 DTD，部分浏览器（尤其 IE）会降级到怪异模式，导致 <meta charset> 不被支持。
HTML5 规范只要求最简声明：，后面紧跟 <code> 和 。任何 XML 风格写法、system ID、public ID 都不必要，反而可能引发兼容问题。
- 删掉所有 DTD 中的 URL、引号、XML 声明
- 确保
是文件第一行，前面不能有任何空格、BOM 或注释 - 动态模板（如 PHP、EJS）中，确认服务端输出前没意外插入空白或 BOM
<meta charset> 写错了，而是三者之一没对上：文件真实编码、HTTP 响应头、HTML 内声明。缺一不可，且都得是 UTF-8（注意大小写和连字符，不能写成 utf8 或 utf_8）。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
