MySQL的utf8存不了emoji是因为其实际为utf8mb3，仅支持3字节编码，而emoji需4字节UTF-8；必须全链路统一配置utf8mb4，包括服务端、数据库、表/列及客户端连接层。
MySQL的utf8为什么存不了emoji
因为utf8在MySQL里根本不是标准UTF-8，而是utf8mb3：它最多只支持3字节编码，而emoji（如?）、部分生僻汉字（如“?”）、甚至某些繁体字都占4字节。MySQL从4.1版（2003年）起就定死了这个限制，后来RFC 3629标准明确要求UTF-8必须支持4字节，但MySQL没改utf8的实现——怕破坏存量数据，于是2010年加了个新字符集叫utf8mb4（mb4 = “most bytes 4”）。
你看到的报错Incorrect string value: '\xF0\x9F\x98\x80' for column，就是客户端送了4字节的UTF-8码点（这里是?），但服务端用utf8去解，直接拒收。
检查当前是否真用了utf8mb4全链路
只改数据库默认字符集没用，必须四层一致：
-
character_set_client、character_set_connection、character_set_results这三个变量都要是utf8mb4（查show variables like 'character_set%';） -
show create database your_db;里DEFAULT CHARACTER SET是utf8mb4 -
show create table your_table;里建表语句显式写了CHARACTER SET utf8mb4（哪怕库设了utf8mb4，老表可能还是utf8或latin1） - 连接字符串里要带
charset=utf8mb4（JDBC加?characterEncoding=utf8mb4，PHP PDO用PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"）
ALTER TABLE ... CONVERT TO和MODIFY COLUMN的区别
用CONVERT TO CHARACTER SET utf8mb4会重写整张表，自动把所有TEXT/VARCHAR字段升级，但有两个坑：
- 如果字段上有索引且长度超767字节（比如
VARCHAR(255)配utf8mb4，255×4=1020字节），会报错Specified key was too long——得先开innodb_large_prefix = ON，并确认innodb_file_format = Barracuda - 它不会改列的排序规则（
COLLATE），得额外指定，例如：CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
而MODIFY COLUMN更可控，适合单字段调整：ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，但得自己列全字段定义，容易漏。
配置文件里init_connect和skip-character-set-client-handshake的作用
init_connect='SET NAMES utf8mb4'会让每个普通用户连接时自动执行该命令，但它对SUPER权限用户无效（比如监控账号、备份账号），所以不能依赖它保底。
skip-character-set-client-handshake = ON才是关键：它强制忽略客户端自己声明的字符集（比如应用连的时候传charset=utf8），全部按服务端character-set-server走。不加这句，只要某次连接指定了utf8，那这次会话就退回到3字节模式，插入emoji照样失败。
真正容易被忽略的是：这个参数只在[mysqld]段生效，且MySQL 8.0.23+才支持；低版本得靠应用层严格控制连接参数，容错性差很多。
