MySQL存Emoji必须全链路使用utf8mb4，包括服务器、数据库、表、字段和连接层；任一环节为utf8（即utf8mb3）或未声明charset，INSERT就会报Incorrect string value错误。
MySQL 存 Emoji 不是“设成 utf8mb4 就完事”，而是全链路必须对齐——服务器、数据库、表、字段、连接层，任意一环卡在 utf8（即 utf8mb3）或未声明 charset，INSERT 就会报 Incorrect string value。
检查 MySQL 当前字符集链是否全为 utf8mb4
执行这两条 SQL，确认 6 项关键变量全部是 utf8mb4：
SHOW VARIABLES LIKE 'character\_set%'; SHOW VARIABLES LIKE 'collation%';
必须为 utf8mb4 的变量有：
character_set_clientcharacter_set_connectioncharacter_set_databasecharacter_set_resultscharacter_set_server-
collation_server（推荐utf8mb4_unicode_ci或utf8mb4_0900_as_cs）
character_set_system 固定为 utf8，可忽略；其余任一项是 utf8 或 latin1，说明配置未生效，或会话层被覆盖。
ALTER TABLE CONVERT TO CHARACTER SET utf8mb4 报错怎么办
常见错误是 Specified key was too long，因为 utf8mb4 单字符最多占 4 字节，而旧版 InnoDB 索引键限制为 767 字节。
例如：VARCHAR(255) 加了索引 → 255 × 4 = 1020 字节 > 767 → 报错。
- 临时解法：把索引字段长度缩到
VARCHAR(191)（191 × 4 = 764，安全） - 根治法：确认并启用
innodb_file_format=Barracuda、innodb_file_per_table=ON、innodb_large_prefix=ON，再加ROW_FORMAT=DYNAMIC -
TEXT类型字段不会随CONVERT自动升级，必须显式执行：MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
应用连接层不配 charset=utf8mb4，前面全白干
即使表结构、服务端全设成 utf8mb4，只要客户端连接没声明字符集，MySQL 仍按默认（常为 latin1 或 utf8）解析字节流，Emoji 进来就是乱码或直接被截断。
- JDBC：
jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8mb4（注意：MySQL Connector/J ≥ 5.1.13；新版驱动不推荐硬写characterEncoding，应依赖init_connect+ 自动探测） - PHP PDO：
mysql:host=localhost;dbname=test;charset=utf8mb4 - Node.js
mysql2：{ charset: 'utf8mb4' } - Django：
OPTIONS={'charset': 'utf8mb4'}必须显式写，ORM 不继承数据库全局设置
为什么 emoji 存进去了却显示为 ? 或乱码方块
这通常不是存储失败，而是读取时字符集错位。重点排查：
- 查询语句执行前，是否触发了
SET NAMES latin1或其他非utf8mb4的会话级设置 - Web 服务（如 Nginx / Apache）是否强制设置了
Content-Type: text/html; charset=iso-8859-1类响应头 - 前端 JS 用
fetch或AJAX获取数据后，是否做了错误的TextDecoder编码转换 - 某些 ORM（如 SQLAlchemy）在建表时未透传
collation，导致字段实际仍是utf8mb3，需手动ALTER COLUMN
最易被忽略的是：连接层配置正确，但应用里某处动态拼接 SQL 时用了 SET NAMES utf8 ——这个 utf8 就是 utf8mb3，它会当场覆盖掉连接字符串里的 utf8mb4 设置。
