HTML中设置UTF-8是明确告知浏览器用UTF-8解码字节流，而非改善字符集；必须置于<head>最前以避免流式解析时因未及时识别编码导致已渲染内容乱码，且需确保文件保存为UTF-8无BOM、服务器响应头一致、全链路统一。
HTML 中设置 UTF-8 不是“改善字符集”，而是明确告诉浏览器：用 UTF-8 编码规则来解码页面字节流。它本身不改变字符集，但能彻底解决乱码——前提是前后端全链路统一使用它。
为什么 meta charset="UTF-8" 必须放在 <head> 最前面
浏览器解析 HTML 是流式进行的。一旦遇到非 ASCII 字符（比如中文、 emoji 或特殊标点），而此时还没读到 meta charset，就会按默认编码（如 ISO-8859-1 或系统本地编码）尝试解码，导致已渲染部分直接乱码，且后续即使遇到 meta 也无法回溯修正。
- 常见现象：
<title>你好</title>显示成你好或一堆问号 - 编辑器保存文件时必须选 “UTF-8 无 BOM” —— 带 BOM 的 UTF-8 开头三个字节
EF BB BF可能被某些旧服务误判为内容，干扰 HTTP 头或 DOCTYPE 识别 - 如果用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（HTML4 写法），优先级低于charset简写，且解析更慢
服务器响应头 Content-Type: text/html; charset=UTF-8 比 meta 更早生效
HTTP 响应头在 HTML 内容传输前就送达浏览器，是编码判定的第一依据。当响应头和 meta 冲突时，现代浏览器（Chrome/Firefox/Safari）以响应头为准；IE 会优先看 meta，但 IE 已淘汰。
- Node.js（Express）设置方式：
res.set('Content-Type', 'text/html; charset=UTF-8') - Nginx 配置：
charset utf-8;（注意不是charset UTF-8;，大小写敏感） - Apache 需确认
AddDefaultCharset UTF-8已启用，或在.htaccess中加AddCharset UTF-8 .html - 若响应头未声明 charset，浏览器才会退回到
meta；若两者都缺失，就可能 fallback 到用户本地区域设置（如 Windows-1252），中文必乱
UTF-8 和 GBK/ISO-8859-1 的实际兼容性差异
UTF-8 对 ASCII 字符（0–127）完全二进制兼容，所以纯英文页面即使没声明 charset 也常能正常显示；而 GBK、ISO-8859-1 等编码无法表示超出其范围的字符，强行解析会导致字节错位、连带破坏后续所有文本。
立即学习“前端免费学习笔记（深入）”；
- 一个中文字符在 UTF-8 中占 3 字节（如
你→E4 BD A0），在 GBK 中占 2 字节（C4 E3）。混用时，GBK 解析器把 UTF-8 的 3 字节当 1.5 个 GBK 字符处理，结果就是两个乱码 + 半个截断 - 数据库连接也要匹配：MySQL 连接字符串需含
?charset=utf8mb4（注意是utf8mb4，不是utf8，后者不支持 emoji） - 表单提交时，若页面是 UTF-8 但
<form accept-charset="GBK">，输入的中文会被按 GBK 编码发送，后端收到的就是错误字节流
调试乱码时最容易忽略的三个环节
多数人只检查 meta 标签，但真正出问题的地方往往在别处。
- 文件实际保存编码 ≠ 编辑器显示的编码：VS Code 右下角状态栏点击编码名可切换并“Save with Encoding”，务必选
UTF-8 - 静态资源（CSS/JS）单独声明编码：CSS 文件开头加
@charset "UTF-8";，JS 无需声明但需确保文件本身是 UTF-8 - 后端模板引擎输出前是否做了二次编码：例如 PHP 的
htmlspecialchars($str, ENT_UTF8)中ENT_UTF8常被漏写，导致中文被转成 HTML 实体后又按错误编码解析
