MySQL 8.0默认字符集改为utf8mb4，是因为旧utf8（即utf8mb3）仅支持3字节编码，无法存储emoji、U+10000起生僻汉字等4字节Unicode字符，插入必报Incorrect string value；utf8mb4才是完整UTF-8实现，自5.5.3引入，8.0起设为默认以补基础能力。
MySQL 8.0 默认字符集是 utf8mb4，不是因为“更高级”或“默认就该这样”，而是因为旧的 utf8（实际是 utf8mb3）根本存不了 emoji、U+10000 起的生僻汉字（比如“?”）、越南语多音符字——一插就报 Incorrect string value。这是硬性能力缺失，不是配置能绕过去的。
为什么 MySQL 的 utf8 不是真正的 UTF-8
MySQL 的 utf8 是个历史别名，只支持最多 3 字节编码，覆盖范围仅限 Unicode 基本平面（BMP，U+0000–U+FFFF）。而 ?、?、?? 这类 emoji，以及中文扩展 C 区字符（如 U+20000），都落在辅助平面，需 4 字节表示。服务端看到 \xF0\x9F\x92\x95 这种字节流，直接拒绝写入。
SHOW CHARSET LIKE 'utf8' 返回的 Maxlen 是 3，不是 4；SHOW VARIABLES LIKE 'character_set_server' 显示 utf8 时，你看到的已经是 utf8mb3。
-
utf8mb4中的 “mb4” 就是 “max bytes 4”，它是 MySQL 对完整 UTF-8 的唯一合规实现，自 5.5.3 引入，8.0 起设为默认 - 从 MySQL 8.0.28 起，
utf8已被官方标记为「已弃用」 - 别指望靠
init_connect='SET NAMES utf8'换救 —— 8.0 下它会被静默映射成utf8mb4，但只作用于会话层，不改字段定义
只改 character-set-server = utf8mb4 远远不够
很多人改完 my.cnf 就以为万事大吉，结果插入 emoji 依然失败。真正要配齐的是三层：
-
[mysqld]段：必须同时加character-set-server = utf8mb4、collation-server = utf8mb4_0900_ai_ci、init_connect='SET NAMES utf8mb4' -
[client]段：default-character-set = utf8mb4（影响mysqldump、mysql命令行等所有客户端工具） -
[mysql]段：default-character-set = utf8mb4（专用于mysql命令行自身，不加可能被忽略）
Windows 用户注意路径：C:\phpEnv\MySQL\my.ini 或 C:\ProgramData\MySQL\MySQL Server X.X\my.ini；Docker 必须挂载自定义 my.cnf 到容器内 /etc/mysql/my.cnf，且权限设为 644，否则静默跳过。
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 容易静默失败
这条命令看着简单，但执行后字段可能仍是 utf8 编码，尤其在以下情况：
- 没显式指定
COLLATE，导致排序规则意外切换（比如从utf8mb4_general_ci变成utf8mb4_0900_ai_ci），大小写行为突变 - 原表
ROW_FORMAT=Compact，而没加ROW_FORMAT=DYNAMIC，CONVERT会退化为 COPY 算法，全表重建并持 SX 元数据锁 -
VARCHAR(255)在utf8mb4下理论最大占 1020 字节，超 InnoDB 默认 767 字节索引上限，报Specified key was too long，但若innodb_large_prefix = OFF，MySQL 可能悄悄截断索引前缀（只索引前 191 字符），导致WHERE name = ?无法走索引
验证是否真生效，不能只看变量：用 mysql 客户端连上去，执行 INSERT INTO t (c) VALUES ('?');，不报错才算过第一关；再查 SELECT HEX(c), c FROM t;，确认返回的是 F09F988E，而不是截断成 EFBFBD（）或报错。
最常被忽略的点是：字段级定义才是真实存储编码。SHOW VARIABLES LIKE 'character%' 全是 utf8mb4，只说明连接层没卡住；SHOW CREATE TABLE 表名 才是真相。哪怕服务端、库、表全设对了，只要某个 VARCHAR 字段还是 CHARACTER SET utf8，emoji 仍进不去。
