必须同时将数据库、表、字段的字符集设为utf8mb4且排序规则为utf8mb4_unicode_ci（或8.0+推荐的utf8mb4_0900_ai_ci），并确保连接层执行SET NAMES utf8mb4，以及my.cnf中配置character-set-server=utf8mb4，三者缺一不可。
MySQL 表和字段没设对 utf8mb4，emoji 一存就变问号或报错
PHP 能正常接收 emoji，但 MySQL 拦在半路——根本原因是默认字符集不支持 4 字节 UTF-8。MySQL 的 utf8 实际是阉割版（最多 3 字节），utf8mb4 才是真正的 Unicode 全集支持。
必须同时改三处，缺一不可：
- 数据库、表、字段的字符集和排序规则都设为
utf8mb4和utf8mb4_unicode_ci（或utf8mb4_0900_ai_ci，MySQL 8.0+ 推荐） - 连接层要显式声明编码：PDO 构造时加
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"，或执行SET NAMES utf8mb4 -
my.cnf或mysqld.cnf中确认全局配置：character-set-server = utf8mb4和collation-server = utf8mb4_unicode_ci，重启 mysqld 生效
常见错误现象：Incorrect string value: '\xF0\x9F\x98\x80'... 就是典型的 4 字节 emoji 被 utf8 截断报错；静默变成问号则多因连接层没设 SET NAMES，导致客户端以为还是 latin1。
PHP 用 PDO 插入 emoji 时乱码，但 mysql 命令行能正常显示
问题不在 PHP 或 MySQL 本身，而在连接初始化阶段没“说清楚”自己要用 utf8mb4。PDO 默认不强制字符集，靠 MySQL 服务端配置兜底，而服务端配置又常被忽略。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 创建 PDO 实例时，务必传入
PDO::MYSQL_ATTR_INIT_COMMAND选项：$pdo = new PDO($dsn, $user, $pass, [ PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4", ]); - 不要依赖
mysql_set_charset()（已废弃）或执行SET CHARACTER SET utf8mb4（它只改 client 字符集，不改 connection 和 results） - 验证是否生效：执行
SHOW VARIABLES LIKE 'character_set%'，重点关注character_set_client、character_set_connection、character_set_results三项是否全为utf8mb4
PHP 接收 POST/GET 中的 emoji 后，存进 MySQL 还是乱码
浏览器发来的请求体本身没问题（现代浏览器默认 UTF-8 编码），但 PHP 可能中途“转码失败”或“误判编码”。尤其当页面 <meta charset="UTF-8"> 缺失，或 Nginx/Apache 没配好默认字符集时，$_POST 值可能被 PHP 错误地按 ISO-8859-1 解码。
关键检查点：
- 前端 HTML 必须有
<meta charset="UTF-8">，且服务器响应头包含Content-Type: text/html; charset=UTF-8 - PHP 不要调用
mb_convert_encoding()或iconv()对$_POST值做无谓转换——除非你明确知道原始编码，否则大概率越转越乱 - 用
mb_detect_encoding($_POST['text'], ['UTF-8'], true)简单验证：返回UTF-8才算真正接收到原生 emoji；若返回 false 或其他编码，说明请求体已在传输链路中损坏
MySQL 8.0+ 开启 utf8mb4 后，ORDER BY 中文或 emoji 排序不准
utf8mb4_unicode_ci 在 MySQL 5.7 是主流选择，但它对 emoji 的排序规则比较宽松（比如把 ? 和 ? 当等价），而 MySQL 8.0+ 的 utf8mb4_0900_ai_ci 更精确，也支持更细粒度的重音/大小写/emoji 区分。
切换建议：
- 修改字段排序规则：
ALTER TABLE comments MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 注意：已有数据不会自动重排，但新插入和查询会按新规则生效
- 如果业务依赖严格字典序（如评论按内容首字符排序），避免用
_ci（case-insensitive）结尾的 collation，可选utf8mb4_0900_as_cs（accent-sensitive + case-sensitive）
真正容易被忽略的是：即使表结构和连接都设对了，只要某一个字段的 COLLATION 还是旧的（比如建表时没显式指定），ORDER BY 就可能退化到隐式转换，导致 emoji 和中文混排时顺序飘忽。
