必须置于内首个可解析标签位置，否则浏览器可能已按默认编码（如iso-8859-1）开始解码，导致中文乱码且刷新无效；其值须严格为“utf-8”，文件保存也须为utf-8无bom，且与http响应头charset一致。
meta charset 放错位置会导致中文乱码
浏览器解析 HTML 时，如果 <meta charset> 出现在 <title></title> 或其他文本内容之后，部分浏览器（尤其是旧版 IE 和某些移动端 WebView）可能已按默认编码（如 ISO-8859-1）开始解码，此时再声明 UTF-8 也晚了。乱码一旦发生，刷新也不一定恢复。
必须确保：<meta charset="UTF-8"> 是 内**首个可被解析的标签**（前面最多允许 <title></title>，但更稳妥的做法是放在最顶上）。
- ✅ 正确顺序：
<meta charset="UTF-8"> <title>中文页面</title>... - ❌ 错误顺序：
<title>中文页面</title> <meta charset="UTF-8">...（Chrome 可能侥幸正常，但不保证） - ⚠️ 注意：HTML 注释、空格、BOM 头不影响解析顺序；但服务端注入的脚本或模板引擎提前输出内容会破坏位置
charset 值写成 utf8 还是 UTF-8？
HTML 标准只接受 UTF-8（带连字符、大写 U、T、F），utf8、utf-8、UTF8 都不符合规范，虽然多数浏览器会容错识别，但存在风险：
- 某些嵌入式浏览器（如微信内置 WebView、部分 IoT 设备）对大小写和连字符敏感，
utf8可能被忽略 - W3C 验证器报错，CI 流程可能拦截
- 服务端响应头若同时设置了
Content-Type: text/html; charset=utf8，与 meta 不一致时，浏览器以响应头为准——而utf8在 HTTP 头中本身就不合法（RFC 7231 要求使用UTF-8）
统一用：<meta charset="UTF-8"> —— 大写开头，带连字符，无空格。
meta charset 和 HTTP 响应头冲突怎么办
当服务器返回的 Content-Type 响应头中指定了 charset（例如 text/html; charset=GBK），它优先级高于 <meta charset>。这时即使写了 UTF-8，中文照样乱码。
排查方法：打开浏览器开发者工具 → Network → 点击 HTML 请求 → 查看 Response Headers 中的 Content-Type。
- ✅ 理想状态：
Content-Type: text/html; charset=UTF-8 - ❌ 常见问题：
charset=GBK（PHP 默认）、charset=ISO-8859-1（某些 Apache 配置）、甚至缺失 charset 参数（此时浏览器按历史启发式猜测） - 修复建议：PHP 加
header('Content-Type: text/html; charset=UTF-8');；Nginx 在server或location块加charset utf-8;；Node.js 的 Express 用res.set('Content-Type', 'text/html; charset=UTF-8')
为什么加了 meta charset 还是乱码？检查这三处
很多开发者反复确认 meta 标签无误，但中文仍显示为方块或问号，问题往往出在源头：
- 文件本身不是 UTF-8 编码：用编辑器（如 VS Code、Sublime）检查右下角编码标识，保存为「UTF-8 无 BOM」；
notepad++中选「编码 → 转为 UTF-8 无 BOM 格式」 - 数据库连接未设 UTF-8：MySQL 需执行
SET NAMES utf8mb4或在连接字符串加?charset=utf8mb4；否则查出的中文字段已是乱码，前端怎么声明都无效 - JavaScript 动态插入的内容没继承编码：比如用
document.write()或 innerHTML 插入含中文的字符串，若 JS 文件本身不是 UTF-8 编码，或未声明<script charset="UTF-8" src="xxx.js"></script>，也可能出问题
真正决定中文能否正确显示的，是“文件存储编码 → 传输编码声明 → 渲染解码方式”三者严格一致。少一环，就卡在乱码上。
