WordPress数据库导入后链接仍为旧域名，须用wp-cli或WP Migrate DB等支持序列化安全替换的工具操作，严禁直接文本替换，否则因PHP序列化长度失效导致白屏或功能异常。
WordPress 数据库导入后链接还是旧域名？
直接替换数据库里所有旧域名字符串，大概率会让网站崩溃——尤其是含序列化数据的 wp_options 和 wp_postmeta 表。php 序列化字符串里包含长度声明，比如 s:12:"example.com";，手动替换会破坏长度值，导致 unserialize 失败，后台白屏或插件失效。
正确做法是用支持序列化安全替换的工具：
- 本地迁移：用
wp-cli命令wp search-replace 'https://old.com' 'https://new.com' --all-tables --network --dry-run先试跑，确认无误再删掉--dry-run - 没 CLI 权限？用
WP Migrate DB插件（注意选 Pro 版或确保免费版已更新至支持多站点序列化），它会自动解析并重写序列化数组 - 绝对不要用 phpMyAdmin 的「查找替换」或文本编辑器全局替换 SQL 文件
导入 SQL 后出现“无法加载脚本”或“REST API 无法访问”
这通常不是域名问题，而是 wp_options 表里的 siteurl 和 home 没同步更新，或者新环境 PHP 配置限制了反序列化深度/大小。
检查和修复步骤：
- 进 phpMyAdmin，查
wp_options表，确认option_name = 'siteurl'和'home'对应的option_value已改为新地址 - 如果用了子目录安装（如
https://new.com/blog），还要核对wp_options中wp_2_options（多站点时）或permalink_structure是否残留旧路径前缀 - PHP 报错
unserialize(): Error at offset？说明某条 meta_value 或 option_value 序列化损坏，可临时在wp-config.php加define('WP_CONTENT_DIR', __DIR__ . '/wp-content');并禁用所有插件，逐个启用排查
多站点（Multisite）下子站域名没批量更新？
单靠替换主站 wp_options 不够。每个子站有自己的选项表（如 wp_2_options、wp_3_options），且 wp_blogs 表里的 domain 和 path 字段也必须改。
操作要点：
- 先改
wp_blogs表：更新domain列为新域名（如sub.new.com），path保持原样（如/或/site2/） - 再对每个子站对应的
wp_{id}_options表执行域名替换（{id}是该子站在wp_blogs中的blog_id） -
wp_sitemeta表里的siteurl也要更新，否则网络仪表盘可能跳转回旧域 - 别忘了检查
wp_users表中user_email是否含旧域名（虽不影响运行，但通知类功能会出问题）
用 mysqldump 导出时漏了关键参数？
默认导出可能丢掉字符集声明或触发器，导致导入后中文乱码或自增 ID 错乱。
导出命令务必加这些参数：
-
mysqldump --default-character-set=utf8mb4 -h localhost -u user -p database_name > dump.sql（utf8mb4防 emoji 和生僻字损坏） - 如果含视图或存储过程，加上
--routines --triggers --events - 避免用 phpMyAdmin「快速导出」，选「自定义」→ 勾选「添加 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT 语句」
- 导入前确认新库字符集也是
utf8mb4_unicode_ci，可在 phpMyAdmin → 数据库 → 操作 → 排序规则里核对
序列化修复不是一次替换就能完事的事，它卡在 PHP 数据结构和 MySQL 文本处理的夹缝里。最常被跳过的，是检查 wp_blogs 和各子站 wp_{N}_options 的联动更新——这里一漏，整个网络就半瘫着。
