根本原因是MySQL默认utf8（即utf8mb3）仅支持3字节UTF-8编码，而Emoji需4字节，必须全面启用utf8mb4：修改my.cnf中[mysqld]、[client]、[mysql]三段配置，重启服务；再逐级执行ALTER DATABASE、ALTER TABLE CONVERT TO、ALTER TABLE MODIFY字段；同时确保应用连接参数（如JDBC的characterEncoding=utf8mb4）和ORM配置同步设为utf8mb4。
MySQL插入Emoji时报错：Incorrect string value
根本原因是默认的 utf8 字符集（即 utf8mb3）最多只支持 3 字节 UTF-8 编码，而 Emoji 多数需要 4 字节（如 ?、❤️、??），直接插入会触发 Incorrect string value 错误。
这不是客户端或应用层编码问题，而是服务端字符集能力不足。必须让 MySQL 支持真正的 UTF-8（即 utf8mb4）。
- 确认当前字符集：
SHOW VARIABLES LIKE 'character_set%';，重点看character_set_client、character_set_connection、character_set_database -
utf8mb4是 MySQL 5.5.3+ 原生支持的，无需额外插件；但旧版本（如 5.1）无法启用 - 仅改客户端连接参数（如加
?charset=utf8mb4）不够——表和列的字符集也必须是utf8mb4
修改数据库、表、字段的字符集为utf8mb4
不能只改库或只改表，三者需协同变更，否则仍可能报错。顺序建议：库 → 表 → 列，并注意索引长度限制（utf8mb4 下单个 VARCHAR(255) 索引会超 767 字节上限）。
- 改库：
ALTER DATABASE your_db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 改表：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 单独改某字段（如
content）：ALTER TABLE your_table MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 若字段有索引且类型是
VARCHAR，需先缩小长度（如从VARCHAR(255)改为VARCHAR(191)），再执行上一步
MySQL配置文件中必须显式设置server端字符集
仅执行 SQL 修改不持久，服务重启后可能回退。必须在 my.cnf（Linux）或 my.ini（Windows）中补全以下几项，且要放在 [mysqld] 段下：
[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
同时建议补充（避免部分客户端绕过连接参数强制使用旧编码）：
-
init_connect='SET NAMES utf8mb4'（对非 SUPER 用户生效） -
skip-character-set-client-handshake（强制忽略客户端声明的字符集，以 server 设置为准；慎用，需确认所有应用兼容） - 修改后必须重启 MySQL 服务，
SHOW VARIABLES再次验证
应用连接字符串和ORM配置要同步适配
即使数据库已支持 utf8mb4，如果连接层没声明，MySQL 仍按默认 utf8 解析请求。不同场景处理方式不同：
- JDBC：
jdbc:mysql://host/db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=UTC（注意是utf8mb4，不是utf8） - Python PyMySQL/MySQLdb：
charset='utf8mb4'传入connect() - Node.js mysql2：
{ charset: 'utf8mb4' } - Django：
OPTIONS = {'charset': 'utf8mb4'}加到DATABASES配置里 - PHP PDO：
new PDO($dsn, $user, $pass, [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"])
漏掉任一环节（比如改了表但没改连接参数），Emoji 就依然存不进去。最常被忽略的是 ORM 的连接配置项，它往往独立于数据库全局设置。
