必须替换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字段——自定义字段（如幻灯片、附件 URL、SEO 插件设置）可能含旧域名 -
wp_usermeta表的meta_value字段（可选）——用户资料里填的个人网站 URL -
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条件限制范围更稳：比如只处理文章（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 跳回。
立即学习“PHP免费学习笔记（深入）”；
