必须将置于最开头，紧贴标签后，确保浏览器尽早按utf-8解析后续内容；旧式http-equiv写法解析晚、易被http头覆盖，不推荐。
怎样用 <meta> 标签正确声明网页字符编码
必须在 中、且越靠前越好（最好紧贴 开始），用 <meta charset="UTF-8"> 声明。这是现代 HTML5 的标准写法，浏览器会立即按该编码解析后续 HTML 内容。
常见错误是写成 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> —— 这种旧式写法虽仍被部分浏览器支持，但解析时机晚、兼容性差，且容易被后续 HTTP 响应头覆盖，不推荐。
关键点：
-
charset属性值不区分大小写，但惯例全大写（UTF-8）或全小写（utf-8）均可；GBK、ISO-8859-1等同理 - 不能写成
charset=utf8（缺短横线），否则多数浏览器识别失败 - 一个页面只能有一个
<meta charset>，重复声明时以第一个为准
为什么 <meta> 声明有时不起作用
根本原因：浏览器在读到 <meta charset> 之前，已根据其他来源决定了初始编码。这些优先级高于 <meta> 的来源包括：
- HTTP 响应头中的
Content-Type: text/html; charset=GBK - BOM（字节顺序标记）：UTF-8 文件若带 BOM（
EF BB BF），浏览器会强制用 UTF-8，无视<meta> - 用户手动在浏览器菜单中“重新编码”，会覆盖所有自动检测逻辑
验证方式：打开浏览器开发者工具 → Network → 查看响应头的 Content-Type 字段；再检查文件是否意外保存为带 BOM 的 UTF-8（可用 VS Code 底部状态栏查看编码并“Save with Encoding”转为 UTF-8 无 BOM）。
<meta> 和 HTTP 头冲突时谁生效
HTTP 响应头的 charset 优先级永远高于 <meta>。例如服务器返回 Content-Type: text/html; charset=ISO-8859-1，即使 HTML 里写了 <meta charset="UTF-8">，浏览器仍按 ISO-8859-1 解析——这会导致中文乱码。
排查与解决：
- 本地开发用 Python
http.server或 Nodehttp-server时，默认不发charset，此时<meta>生效 - Apache 需检查
AddDefaultCharset指令；Nginx 要确认未配置charset指令 - PHP 输出前调用
header('Content-Type: text/html; charset=UTF-8');可显式覆盖
不同编码下中文显示异常的典型表现
不是所有乱码都源于编码声明错误，需结合现象反推：
- 显示为 “æ些æå” → 实际是 UTF-8 字节被当 ISO-8859-1 解析，说明服务端或
<meta>声明了错误编码 - 显示为 “涓€浜涙–瀛椾负” → GBK 字节被当 UTF-8 解析，常见于 Windows 记事本保存为 ANSI（即 GBK）但声明了 UTF-8
- 显示为 “” 或方块 → 字体缺失或字符本身不在当前编码范围内（如用 ASCII 打开含中文的文件）
最稳妥的做法：统一用 UTF-8 编码保存文件 + <meta charset="UTF-8"> + HTTP 响应头也设为 UTF-8。任何环节漏掉，都可能让中文变成问号或乱码。
