mysql的utf8实为utf8mb3，仅支持3字节编码，而emoji需4字节utf8mb4；必须全链路（服务端、连接、库、表、字段）统一设为utf8mb4并重启验证，否则插入会报incorrect string value或显示乱码。
因为 MySQL 的 utf8 不是真正的 UTF-8，它最多只支持 3 字节编码，而 emoji（如 ?、❤️、??）属于 Unicode 补充平面字符，需要 4 字节 UTF-8 编码。只要连接、表、字段任一环节还是 utf8（即 utf8mb3），插入 emoji 就会触发 Incorrect string value 或变成 ???。
ThinkPHP5 的 DB_CHARSET='utf8' 只改了连接层
设为 'utf8' 会让 PDO 连接使用 charset=utf8，但这个值在 MySQL 中对应的是 utf8mb3，不是 utf8mb4。即使数据库和表已设成 utf8mb4，只要连接没切过去，MySQL 服务端仍按 utf8 解析请求，导致四字节 emoji 被拒绝或截断。
- ThinkPHP5 配置中应改为
'DB_CHARSET' => 'utf8mb4' - 同时确保 DSN 中也显式带上
;charset=utf8mb4（如使用自定义 DSN） - 验证是否生效：执行
Db::query('SELECT @@character_set_client, @@character_set_connection, @@character_set_results')，三个值必须全是utf8mb4
字段字符集没同步更新是最常见漏点
哪怕数据库、表都设成了 utf8mb4，只要存 emoji 的那个字段（比如 content 或 nickname）仍是 utf8_general_ci，插入就会立刻失败。MySQL 字符集优先级是：字段级 > 表级 > 数据库级。
- 查字段实际字符集：
SHOW FULL COLUMNS FROM your_table LIKE 'content'; - 单独修改字段：
ALTER TABLE your_table MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 别只用
CONVERT TO——它不保证所有字段都升级，尤其 TEXT/VARCHAR 类型可能被忽略
PDO 查询缓冲未开启会引发连锁报错
如果在未取完前一个查询结果时又发起新查询（比如循环里嵌套 Db::table()->find()），PDO 默认不缓存结果，MySQL 服务端还占着游标，就会报 SQLSTATE[HY000]: General error: 2014。这个错误常和 emoji 报错一起出现，让人误以为是字符集问题。
- 在 database.php 的
'params'中加上：PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true - 注意键名必须是常量，不能写成字符串
'MYSQL_ATTR_USE_BUFFERED_QUERY' -
PDO::ATTR_EMULATE_PREPARES => true也能缓解，但不如开缓冲直接可靠
服务端配置不到位，前端再怎么配也没用
如果 MySQL 服务端的 character_set_server 仍是 latin1 或 utf8，新建库/表/字段默认就不会用 utf8mb4，老数据迁移后新插入照样失败。
- 检查命令：
SHOW VARIABLES LIKE 'character_set%';，重点关注character_set_server - 需在 my.cnf 的
[mysqld]段加入：character-set-server = utf8mb4 - 同时配置
[client]和[mysql]段的default-character-set = utf8mb4 - 改完必须重启 MySQL 服务
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
