直接结论：乱码不是“显示问题”，而是数据被错误解释的结果；必须先确认字段真实编码，再针对性修正排序规则，不能无脑 convert to charset。
查清字段真实编码状态，别猜
执行 SELECT HEX(column_name) FROM wp_posts LIMIT 1; 查看返回值。如果结果是类似 E4B8ADE69687（UTF-8 编码的“中文”），说明数据本身是 UTF-8 字节流，只是当前列声明为 latin1 导致 MySQL 按 latin1 解释成乱码；如果返回 C4E3BAC3 这类短十六进制串，大概率是原始 latin1 存储、后来被当 utf8mb4 读取导致的二次错解。
只有确认了真实编码，才能决定下一步是改列声明还是重建数据。
- 真实编码是 UTF-8 → 只需
ALTER TABLE ... MODIFY ... CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 真实编码是 latin1 → 需先用
CONVERT TO CHARACTER SET latin1强制重读，再转 utf8mb4，否则会雪上加霜 - 不确定？先备份，再在测试表上跑小样本验证
wp-config.php 中 DB_CHARSET 必须设为 utf8mb4
旧配置里常见 define('DB_CHARSET', 'utf8');，这在 MySQL 8.0+ 已被弃用，实际等价于 utf8mb3，不支持 emoji 和部分汉字。必须改成：
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
注意：DB_COLLATE 不留空更稳妥，尤其当数据库已存在旧表时。
生产级WordPress REST API集成，用于管理文章、页面、媒体、WooCommerce产品、Elementor内容、SEO元数据、ACF及JetEngine字段
- 改完后清空 WordPress 对象缓存（如有）
- 检查 PHP 的
default_charset是否为UTF-8（php.ini 中，注意是连字符，不是 utf8） - 若用 Nginx + PHP-FPM，确认
fastcgi_param PHP_VALUE "default_charset = UTF-8";已启用
修改表和列的排序规则要分步，不能跳过“连接层”
即使数据库、表、列都设成了 utf8mb4_unicode_ci，如果 phpMyAdmin 连接时没指定 charset，仍会走默认 latin1。所以必须同步设置：
- MySQL 服务端：在
my.cnf的[mysqld]下加character-set-server = utf8mb4和collation-server = utf8mb4_unicode_ci - phpMyAdmin：在
config.inc.php中设$cfg['Servers'][$i]['charset'] = 'utf8mb4';和$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4'; - WordPress 表结构：对关键表如
wp_posts、wp_options，逐个执行ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;—— 仅适用于真实编码已匹配的情况
旧数据转换失败后最常忽略的一点
很多人执行完 CONVERT TO 发现内容变成 æ–‡ 或更糟，是因为该命令会强制重新编码字节，而原始字段若已被错误解释过一次，字节已损坏。此时唯一可靠路径是：
- 导出原始表为 SQL（选“以十六进制导出 BLOB”）
- 用文本编辑器搜索
INSERT INTO `wp_posts`后的十六进制值，人工比对是否符合 UTF-8 编码规律 - 写脚本按真实编码批量重建 INSERT 语句，再导入
没有捷径。所谓“一键修复插件”多数只做表结构变更，对已错解的数据无效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
