phpMyAdmin不修复乱码，需从MySQL服务端默认字符集、phpMyAdmin连接配置、WordPress配置及旧数据真实编码四方面系统解决；盲目执行CONVERT会毁数据，必须先用HEX验证再针对性修正。
直接说结论：phpmyadmin 本身不“修复”乱码，它只是工具；真正要修的是数据库连接层、表结构声明和已有数据的真实编码状态。盲目执行 alter table ... convert to character set utf8mb4 会把半损坏的数据彻底搞废。
MySQL服务端默认字符集不是utf8mb4
这是90%乱码的起点。phpMyAdmin页面显示问号或方块，往往不是界面问题，而是MySQL启动时用latin1当默认字符集。
- 登录MySQL命令行，执行
SHOW VARIABLES LIKE 'character_set_server';—— 如果返回latin1，必须改配置 - 编辑
/etc/mysql/my.cnf（或/etc/my.cnf），在[mysqld]段下加两行：character-set-server = utf8mb4collation-server = utf8mb4_unicode_ci - 重启MySQL：
sudo systemctl restart mysql（或mysqld） - 重启后新建的数据库/表默认就是
utf8mb4，但旧表不会自动变
phpMyAdmin连接层没设对utf8mb4
即使MySQL服务端已设好，phpMyAdmin仍可能用utf8（即utf8mb3）初始化连接，导致emoji或生僻字存取异常。
- 打开
config.inc.php，找到对应服务器配置块（如$cfg['Servers'][$i]） - 显式设置：
$cfg['Servers'][$i]['charset'] = 'utf8mb4';$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4'; - 确认PHP的
default_charset在php.ini中是UTF-8（注意是连字符，不是utf8） - 别依赖
SET NAMES utf8——MySQL 8.0+已弃用utf8别名，它实际指向utf8mb3
旧WordPress表数据编码状态不明，不能直接CONVERT
很多教程让直接跑ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4，这非常危险。如果字段里存的是被当latin1解释的UTF-8字节，二次转换就全毁了。
- 先查真实编码：
SELECT HEX(post_title) FROM wp_posts LIMIT 1; - 如果返回类似
E4B8ADE69687（“中文”的UTF-8十六进制），说明数据本体是UTF-8，只是表声明错了 - 此时应改列定义，而非转换内容：
ALTER TABLE wp_posts MODIFY post_title TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 如果返回类似
C4E3BAC3（GB2312或GBK的HEX），说明原始录入就是GB系编码，需按真实来源重建 - WordPress核心文件（如
wp-config.php）必须保存为UTF-8 无BOM，否则PHP输出头部污染会导致整个页面乱码
WordPress自身配置没对齐utf8mb4
phpMyAdmin只是看门人，WordPress才是数据主人。它自己的配置错一位，前端照样乱。
立即学习“PHP免费学习笔记（深入）”；
- 检查
wp-config.php是否有：define('DB_CHARSET', 'utf8mb4');define('DB_COLLATE', 'utf8mb4_unicode_ci'); - 没有就加上；有但值是
utf8或空字符串，必须改成utf8mb4 - 通过phpMyAdmin进到
wp_options表，查option_name = 'blog_charset'，值应为UTF-8（注意大小写和连字符） - 如果用宝塔或Docker，注意MySQL是否监听TCP（
skip-networking必须注释掉），且$cfg['Servers'][$i]['host']别写localhost（容器内DNS解析常失败）
最易被忽略的点：旧数据的HEX值判断必须做，不能跳过；CONVERT TO是最后手段，不是第一步。还有，utf8mb4四个字母一个都不能少，utf8在MySQL 8.0+里已经不是你想要的那个UTF-8了。
