必须替换wp_options表的option_value（WHERE option_name IN ('siteurl','home')）、wp_posts表的guid和post_content、wp_postmeta表的meta_value、wp_usermeta和wp_comments表的相关字段，且需逐条执行SQL并验证。
直接执行 sql 是最稳妥的方式，但必须分表、分字段操作，不能只改 post_content 就完事。 否则会出现后台跳转到旧域名、图片 404、rss 订阅失效等问题。
哪些表和字段必须一起替换？
WordPress 中域名会散落在多个地方，漏掉任何一个都可能引发异常：
-
wp_options表的option_value字段（WHERE option_name IN ('siteurl', 'home')）——决定后台入口和首页地址 -
wp_posts表的guid字段——RSS 和某些插件依赖它，虽然不用于前端展示，但不能忽略 -
wp_posts表的post_content字段——正文里的链接、图片地址、iframe 等 -
wp_postmeta表的meta_value字段——自定义字段中可能存有旧域名（如幻灯片、附件 ID 对应的 URL） -
wp_usermeta表的meta_value字段（可选）——如果用户资料里填了带域名的个人网站，也建议扫一遍 -
wp_comments表的comment_content和comment_author_url字段（可选）——评论区链接也要同步
SQL 语句怎么写才安全？
别用一条大 SQL 拼所有表，每条单独执行、逐条验证。注意这些细节：
- URL 必须完整匹配协议和斜杠：用
'https://old.com'，别用'old.com'，否则可能误替example-old.com - 如果旧域名带尾部斜杠（
'https://old.com/'），新域名也得带，否则REPLACE()不会匹配不带斜杠的变体 - 执行前先用
SELECT预览：例如SELECT post_content FROM wp_posts WHERE post_content LIKE '%old.com%' LIMIT 5; - 加
WHERE条件限制范围更稳：比如只处理文章（post_type = 'post'），或限定 ID 范围（WHERE ID BETWEEN 100 AND 500）
为什么不能只靠 phpMyAdmin 的「查找替换」界面？
那个可视化功能看着方便，但有硬伤：
- 它默认只作用于当前打开的数据表，不会自动跨表扫描
- 字段类型为
LONGTEXT（比如post_content）时，界面可能截断内容，导致部分匹配失败 - 无法对
guid或meta_value这类非纯文本字段做条件过滤，容易误伤序列化数据（虽然REPLACE()本身不破坏结构，但界面工具不保证） - 没有执行日志，出错后难追溯哪条没生效
最后提醒一个容易被忽略的点
替换完数据库，别急着关 phpMyAdmin。立刻检查 wp_options 表里 siteurl 和 home 两条记录是否已更新——这是整个站点能否正常访问的开关。如果这两条还是旧值，哪怕其他全替对了，后台也会 302 跳回老域名，且前台 CSS/JS 加载失败，页面变成纯文字。这个检查动作花不了 10 秒，但能省下两小时排查时间。
立即学习“PHP免费学习笔记（深入）”；
