必须把数据库、表、字段的字符集都设为utf8mb4，且连接层也要用utf8mb4，否则Emoji一定会变成问号或乱码；MySQL的utf8实为utf8mb3，仅支持3字节字符，而Emoji需4字节，必须用utf8mb4才能完整存储。
直接说结论：必须把数据库、表、字段的字符集都设为 utf8mb4，且连接层也要用 utf8mb4，否则 emoji 一定会变成问号或乱码。
为什么默认 utf8 不行？
MySQL 的 utf8 实际是 utf8mb3，最多只支持 3 字节 Unicode 字符；而 Emoji（比如 ?、?、??）普遍需要 4 字节，必须靠 utf8mb4 才能完整存储。
常见错误现象：INSERT 成功但查出来是 ??? 或空格；phpMyAdmin 导入后显示 “Invalid utf8 character string” 或直接截断；导出再导入丢失表情。
- 不能只改数据库字符集，表和字段也得同步改
- phpMyAdmin 自身连接用的是
SET NAMES utf8，得手动改成utf8mb4 - SQL 文件开头如果没有
SET NAMES utf8mb4，导入时会按旧编码解析
导入前必须做的三件事
缺一不可，顺序不能错：
- 确认 MySQL 版本 ≥ 5.5.3（
utf8mb4支持起始版本）；5.7+ 更稳妥 - 在 phpMyAdmin 中，进对应数据库 → “操作” → 把“排序规则”改成
utf8mb4_unicode_ci（不是utf8_general_ci） - 对每个含 Emoji 的表，点“结构” → “更改” → 把每个
TEXT、VARCHAR字段的“排序规则”也设为utf8mb4_unicode_ci
如果表已存在且数据量大，改字段字符集可能锁表，建议在低峰期操作。
SQL 文件里要加哪些关键语句？
光改库和表不够，导入时连接层必须用 utf8mb4。在 SQL 文件最开头插入这两行：
SET NAMES utf8mb4; SET CHARACTER SET utf8mb4;
如果你的 SQL 文件是从其他环境导出的，检查是否有 CREATE TABLE 语句里带 CHARSET=utf8 或 COLLATE=utf8_general_ci，全部替换成：
CHARSET=utf8mb4COLLATE=utf8mb4_unicode_ci
注意：utf8mb4_bin 虽然也支持 Emoji，但大小写敏感、排序行为不同，日常用 utf8mb4_unicode_ci 更稳妥。
phpMyAdmin 导入界面的隐藏设置
上传 SQL 文件后，别急着点“执行”。先点右上角“更多选项”，勾选：
- “部分导入：跳过查询中的错误” → 关掉（否则出错就停，Emoji 插不进去）
- “使用 UTF-8 编码进行上传” → 必须勾上（告诉 phpMyAdmin 别用系统默认编码读文件）
如果文件大于 2MB，还要确认 upload_max_filesize 和 post_max_size PHP 配置是否足够——但这和 Emoji 无关，只是导入失败的常见干扰项。
真正容易被忽略的是：即使所有设置都对了，如果客户端（比如浏览器）本身没声明 utf8mb4，phpMyAdmin 的 AJAX 请求仍可能退回到 utf8。遇到导入后仍是问号，立刻去检查 MySQL 的 character_set_client、character_set_connection、character_set_results 三个变量是否全为 utf8mb4——不是靠猜，而是执行 SHOW VARIABLES LIKE 'character_set%'; 看结果。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
