MySQL的utf8实为utf8mb3，仅支持3字节编码，无法存储emoji、生僻汉字等4字节字符，会导致静默截断或问号乱码；彻底规避必须全链路（服务端、数据库、表、连接层）统一升级至utf8mb4。
MySQL 的 utf8 不是 UTF-8，它根本存不了 emoji、部分生僻汉字和很多 Unicode 4.0+ 字符——用它就是默认接受静默截断或报错。
为什么 utf8 在 MySQL 里会丢数据却不报错
MySQL 5.7 的 utf8 实际叫 utf8mb3，只支持最多 3 字节的 UTF-8 编码。而标准 UTF-8 允许 4 字节（U+10000 起），比如：?（U+1F30D）、✅（U+2705）、䶮（U+2010E）、éššá 中某些组合。当你插入这些字符时：
- MySQL 直接砍掉第 4 字节，不警告、不报错、不触发
Data too long； - 字段显示“少了一截”，例如
"Hi ?"存成"Hi ?"； - 如果字段是
VARCHAR(10)，实际只占 9 字节，但第 10 字节被截断后仍算合法长度。
哪些场景下 utf8 必然出问题
只要业务涉及以下任意一种，utf8 就不是“可能出错”，而是“一定会出错”：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用户昵称/评论/富文本中含 emoji（微信、钉钉、App 用户输入）；
- 身份证姓名含生僻字（如“䶮”“?”“婠”）；
- 多语言混合内容（法语
é、捷克语š、西班牙语á等扩展拉丁字符在某些边界组合下也需 4 字节）； - 第三方 API 返回的 JSON 含 emoji 或特殊符号（如支付回调、物流状态）。
改 utf8mb4 不是“升级”，是补全基础能力
utf8mb4 是 MySQL 原生支持的完整 UTF-8 实现（5.5.3+ 可用），不是插件，也不需要额外安装。它和 utf8 的关键差异在于：
- 向后兼容：把
utf8表改成utf8mb4，原有数据不会损坏，无需重导； - 单字符最大 4 字节，覆盖全部 Unicode 字符（U+0000–U+10FFFF）；
- 排序规则更合理：
utf8mb4_unicode_ci比utf8mb4_general_ci对多语言支持更准，推荐优先选； - InnoDB 行长度限制要注意：原来
VARCHAR(255)在utf8mb4下最多占 1020 字节（255×4），可能触发Row size too large，必要时改TEXT或调小长度。
检查是否真在用 utf8mb4，光看配置文件没用
必须逐层验证，漏一环就白改：
- 连接层：
SHOW VARIABLES LIKE 'character_set%';中character_set_client、character_set_connection、character_set_results都得是utf8mb4； - 数据库级：
SHOW CREATE DATABASE your_db;看DEFAULT CHARACTER SET是否为utf8mb4； - 表级：
SHOW CREATE TABLE your_table;确认建表语句含CHARACTER SET utf8mb4，不是只靠数据库默认值； - 客户端连接字符串必须显式带
charset=utf8mb4（JDBC：useUnicode=true&characterEncoding=utf8mb4；Python：charset='utf8mb4'）。
最容易被忽略的是：表结构本身可能仍是 utf8，哪怕数据库和连接都设对了——因为 ALTER DATABASE 不会影响已有表。生产环境上线前，务必用 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 显式重写表，且先备份。
