必须确保数据库和表字符集为utf8mb4且导出时显式选择utf8mb4编码，否则emoji会截断、乱码或显示为问号；导入时目标库各字符集参数也须均为utf8mb4。
导出前必须确认数据库和表的字符集是 utf8mb4
Emoji 占用 4 字节，而传统 utf8（即 utf8mb3）在 MySQL 中最多只支持 3 字节字符，强行存 Emoji 会截断或报错。phpMyAdmin 导出时不会自动升级字符集，它只是按当前表定义读取数据。
检查方法：在 phpMyAdmin 中点开对应表 → «结构» 标签页 → 查看 «排序规则» 列，应为类似 utf8mb4_unicode_ci 或 utf8mb4_0900_ai_ci；如果不是，需先执行：
ALTER TABLE `your_table` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：CONVERT TO 会重写整张表，大表慎操作；若只需改列，用 MODIFY COLUMN 更精准。
导出时选择「自定义」并勾选 utf8mb4 编码
默认「快速» 导出使用的是 utf8 编码，即使表本身是 utf8mb4，导出文件也会把 Emoji 替换为问号或乱码。
正确操作路径：选中表 → «导出» → «自定义» → 向下滚动到 «格式特定选项» → 找到 «导出字符集» → 从下拉菜单中明确选择 utf8mb4（不是 utf8，也不是「自动」）。
其他关键勾选项：
-
包含列名：建议勾上，方便后续导入或查看 -
导出视图/例程/事件/触发器：按需，与 Emoji 无关 -
禁用外键检查：仅当导出含外键约束的全库时有用
避免用「SQL」格式导出再手动改 CHARSET
有人尝试导出 SQL 文件后，把 DEFAULT CHARSET=utf8 全局替换成 utf8mb4，这看似合理，但有隐患：
— 如果原表已有 utf8 字符集，导出的 INSERT 语句里的 Emoji 实际已被 phpMyAdmin 截断或转义，替换字符集无法恢复原始数据；
— CREATE TABLE 语句中的 CHARSET 修改只影响新建表，不修复已丢失的内容。
真正安全的做法只有两个前提：表本身用 utf8mb4 + 导出时显式指定 utf8mb4 编码。缺一不可。
导入时也要匹配 utf8mb4，否则 Emoji 仍会损坏
导出只是第一步。如果把这个 SQL 文件导入到一个默认字符集仍是 utf8 的目标库（比如旧版 MySQL 或未配置 my.cnf 的环境），Emoji 依然显示为 ?? 或空白。
验证目标库是否就绪：
SHOW VARIABLES LIKE 'character_set%';<br>SHOW VARIABLES LIKE 'collation%';
重点关注：character_set_server、collation_server、以及连接层的 character_set_client 和 character_set_connection 是否都为 utf8mb4。只要其中任意一层是 utf8，Emoji 就可能被降级处理。
最稳妥的导入方式：用 phpMyAdmin 导入页同样选择 utf8mb4 编码；或命令行导入时加参数：mysql --default-character-set=utf8mb4 -u user db_name 。
Emoji 支持不是开关，是一条链路：建表 → 写入 → 查询 → 导出 → 传输 → 导入 → 显示。任一环节掉链，就看不到 ? 而是 。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
