答案是需逐个检查并统一核心表的Collation为utf8mb4_unicode_ci，因数据库默认字符集不影响已有表，混合状态会导致emoji失败或乱码；须用ALTER TABLE CONVERT TO批量转换，同时修复超长索引并匹配wp-config.php及MySQL服务配置。
确认当前表字符集和排序规则
直接进 phpmyadmin 看 wp_posts、wp_comments 这类核心表的“结构”页，右上角“操作”标签里能看到当前 collation 值。常见问题不是“全是 latin1”，而是混合状态：比如 wp_options 是 utf8mb4_unicode_ci，但 wp_postmeta 还卡在 utf8_general_ci —— 这种不一致会导致 emoji 插入失败或乱码，且后续升级可能报错。
别只看数据库默认字符集，它不影响已有表；必须逐个检查每张表的实际 Collation。
批量转换表字符集到 utf8mb4
phpMyAdmin 不支持一键全库转 utf8mb4，得手动操作。进“SQL”页，用 ALTER TABLE 逐个改，推荐按以下顺序执行（避免外键冲突）：
- 先改
wp_users和wp_usermeta - 再改
wp_posts、wp_postmeta、wp_comments、wp_commentmeta - 最后改
wp_options、wp_terms等其他表
每条语句类似：
ALTER TABLE `wp_posts` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;注意：用
CONVERT TO 而不是 CHARACTER SET 单独设，前者会同时转换列、索引、存储格式；后者只改表级声明，实际数据仍可能是 latin1 编码。
修复可能损坏的索引长度
utf8mb4 比 utf8 多占 1 字节，原来 VARCHAR(255) 的字段如果建了全文索引或前缀索引，可能超长报错：Specified key was too long; max key length is 767 bytes。
遇到这错误，得缩短索引字段长度：
- 查哪些索引太长：
SHOW INDEX FROM wp_posts WHERE Key_name != 'PRIMARY'; - 删掉冗余索引：
DROP INDEX post_name ON wp_posts; - 重建时限制前缀长度：
CREATE INDEX post_name ON wp_posts (post_name(191));
WordPress 4.2+ 默认已用 191 作为安全长度，但老站迁移常遗留旧索引。
确保 wp-config.php 和 MySQL 配置匹配
只改表没用，PHP 和 MySQL 服务层也得配合。检查 wp-config.php 是否有这两行：
define('DB_CHARSET', 'utf8mb4');<br>define('DB_COLLATE', 'utf8mb4_unicode_ci');
同时确认 MySQL 的 my.cnf 含这些配置（否则连接层仍用 utf8）：
[client]<br>default-character-set = utf8mb4<br><br>[mysqld]<br>character-set-server = utf8mb4<br>collation-server = utf8mb4_unicode_ci
改完要重启 MySQL 服务，且 phpMyAdmin 连接必须新建（旧连接缓存旧字符集）。
最易忽略的是：改完表后，新插入的数据才走 utf8mb4；旧数据如果原本是 latin1 编码存的乱码，CONVERT TO 不会自动修复——得用 CONVERT(CAST(CONVERT(col USING latin1) AS BINARY) USING utf8mb4) 这类双重转换，但风险高，建议先备份。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
