直接用phpmyadmin迁移wordpress 6.x数据库可行，但必须清空新库再导入、选自定义导出并设utf8mb4编码、禁用扩展插入，且替换域名须用wp-cli或better search replace处理序列化数据，同时删除wp-config.php中wp_home/wp_siteurl常量。
直接用 phpmyadmin 迁移 wordpress 6.x 数据库是可行的，但必须手动处理 wp_options 表里的 siteurl 和 home 值，否则网站白屏或跳转回旧域名——这是最常卡住的一步。
导出时必须选“自定义”而非“快速”
WordPress 6.x 使用了更严格的序列化数据校验（尤其在 postmeta、options、termmeta 表中），如果导出时用“快速”模式，phpMyAdmin 默认不包含 CREATE DATABASE 和 SET NAMES 语句，导入后容易出现乱码或插入失败。
- 导出页勾选“自定义”，格式选
SQL - 务必勾选“添加 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER 语句”——避免表冲突
- 编码选
utf8mb4（不是utf8），并确认“导出字符集”和“导出方式”都设为utf8mb4_unicode_ci - 取消勾选“扩展插入”（即不要合并多行 INSERT）——大数据库导入时更稳定
导入前要先清空新数据库再执行
直接导入覆盖旧表会触发 WordPress 6.x 的表结构校验失败（比如 wp_users 缺少 user_activation_key 字段），导致后台无法登录。正确做法是先清空，再导入。
- 登录新主机 phpMyAdmin → 选中目标数据库 → 点击“操作” → “清空表（TRUNCATE）” → 确认
- 不要点“删除数据库”，只清空内容；否则 wp-config.php 里配的表前缀可能失效
- 导入时上传 .sql 文件后，**不要勾选“部分导入”或“忽略错误”**——WordPress 6.x 对 SQL 语法更敏感，忽略错误会导致关键表（如
wp_options）缺失
替换域名必须用专业工具，不能靠文本搜索替换
WordPress 6.x 大量使用 PHP 序列化数据（例如菜单、小工具、主题设置），直接用文本编辑器全局替换旧域名会破坏序列化长度，导致 unserialize() 失败，页面空白或后台崩溃。
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 导入完成后，**立刻用 wp-cli 执行：
wp search-replace 'https://old.com' 'https://new.com' --all-tables --dry-run**（先试运行） - 确认无误后去掉
--dry-run再执行真实替换 - 若无 wp-cli 权限，改用插件
Better Search Replace（注意：必须启用“对序列化数据安全替换”选项） - 切勿在 phpMyAdmin 里手动 UPDATE
wp_options的siteurl和home后就以为万事大吉——其他表里还有上百处隐藏 URL
wp-config.php 配置项必须同步更新
WordPress 6.x 默认启用 WP_HOME 和 WP_SITEURL 常量强制覆盖数据库值，如果旧配置残留，即使数据库已替换，前台仍跳转旧地址。
- 检查
wp-config.php是否存在这两行：define('WP_HOME', 'https://old.com');和define('WP_SITEURL', 'https://old.com'); - 如有，直接删掉或改成新地址；否则 WordPress 6.x 会优先读取常量而非数据库
- 同时确认
DB_CHARSET是'utf8mb4'，DB_COLLATE为空（WordPress 6.x 不再推荐填值） - 如果新主机 PHP 版本 ≥ 8.1，建议加上：
define('WP_MEMORY_LIMIT', '256M');防止大数据库操作中途超限
最关键的细节不是“能不能导出”，而是“导出后有没有破坏序列化结构”——哪怕只有一处 a:3:{s:4:"name";s:5:"admin";...} 里数字写错，WordPress 6.x 就会拒绝加载整个选项字段。所以别图快，每一步都要验证：导入后看 phpMyAdmin 里各表行数是否和旧库一致，再跑一次 wp search-replace --all-tables --report 确认替换条目数合理。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
