必须置于最前面，且为唯一推荐写法；值须为标准编码名，服务端响应头优先级更高。
charset meta 标签必须放在
浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、日文），会立即用当前猜测的编码去解码；如果此时还没读到 <meta charset="UTF-8">，就可能按默认编码（如 ISO-8859-1）错误解析，导致后续所有文本乱码，且无法回退修复。
所以它不能塞在 <title></title> 后面，也不能和 <link> 或 <script></script> 混排——必须是 中第一个可执行的标签（注释和空格不算）：
<head> <meta charset="UTF-8"> <title>页面标题</title> <meta name="description" content="..."> </head>
只认 charset 属性，不接受 http-equiv 写法
HTML5 明确废弃了旧式写法 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">。虽然多数浏览器仍兼容，但存在两个实际问题：
- 部分严格模式解析器（如某些 SSR 渲染引擎或校验工具）会警告或拒绝该写法
- 若服务器已通过 HTTP 响应头返回了
Content-Type: text/html; charset=GBK，而页面又用了http-equiv，两者冲突时行为不可控
正确且唯一推荐的写法只有这一种：
立即学习“前端免费学习笔记（深入）”；
<meta charset="UTF-8">
值必须是标准编码名称，utf8 和 utf-8 都合法但推荐后者
HTML5 规范接受大小写不敏感的编码名，也接受带/不带连字符的变体。但要注意：
-
UTF8、utf8、UTF-8、utf-8全部被识别为 UTF-8 -
gbk、GB2312、Big5等也支持，但仅限 legacy 场景；现代项目一律用UTF-8 - 不要写
utf_8、unicode、default这类非标准名，会导致浏览器 fallback 到默认编码
实际部署中，统一用小写连字符形式最稳妥：
<meta charset="UTF-8">
服务端响应头比 meta 标签优先级更高
如果服务器在 HTTP 响应头里明确写了 Content-Type: text/html; charset=ISO-8859-1，那么无论 <meta charset> 怎么写，浏览器都会以响应头为准——这是规范强制要求。
这意味着：
- 本地双击打开 HTML 文件（file:// 协议）时，没有响应头，才真正依赖
<meta charset> - 上线前务必检查服务器配置（Nginx/Apache/Node.js 等），确保响应头未覆盖或冲突
- 用浏览器开发者工具的 Network → Response Headers 查看真实返回的
Content-Type
常见疏漏点：PHP 文件开头有 BOM 或空格，导致 header() 失败，最终没发 Content-Type，浏览器只能靠 meta 标签——这种“侥幸生效”其实掩盖了更深层的问题。
