最可靠方法是手动在phpmyadmin的sql窗口执行三条update语句：分别更新wp_options的siteurl/home、wp_posts的post_content和guid字段，且必须带where条件精准匹配旧域名，执行前需导出这两张表并验证guid是否更新完毕。
直接在phpMyAdmin里执行UPDATE语句最可靠
别信“搜索替换”界面能搞定所有情况——它只扫描当前页数据、不支持跨字段批量改、还可能漏掉guid或post_content里的协议相对路径（//old.com/）。真要批量换链接，必须进SQL窗口手写UPDATE。
你得同时改三处，缺一不可：
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://old.com', 'https://new.com') WHERE option_name IN ('siteurl', 'home');UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://old.com', 'https://new.com') WHERE post_content LIKE '%http://old.com%';UPDATE wp_posts SET guid = REPLACE(guid, 'http://old.com', 'https://new.com') WHERE guid LIKE '%http://old.com%';
注意表前缀：如果你的表不是wp_开头（比如wp123_posts），所有语句里的wp_都要替换成你实际的前缀。
为什么WHERE条件不能省，也不能写错
WHERE post_content LIKE '%http://old.com%'不是可选项，是保命线。没它，MySQL会扫全表每一条记录，哪怕post_content是空的、是纯文字、甚至根本没出现旧域名，也照样执行REPLACE()——看似没报错，但可能把某些特殊字符或序列化字符串结构意外破坏。
更关键的是匹配精度：
- 如果旧链接带端口（
http://old.com:8080），必须完整写进LIKE和REPLACE里，否则不生效 - 协议相对路径（
//old.com/）要单独补一条：REPLACE(post_content, '//old.com/', '//new.com/') - 绝对路径结尾斜杠（
/wp-content/uploads/）必须严格一致，多一个少一个都会漏换
执行前必须导出wp_posts和wp_options表
这条UPDATE没有撤销键。一次执行，永久覆盖。网上说“导出整个库”太慢，其实你只要导出两张表就够了：
- 在phpMyAdmin左侧选中
wp_posts→ 导出 → 格式选SQL→ 勾选“仅数据” → 下载 - 同样操作导出
wp_options
别用“快速导出”，选“自定义”，确保勾上DISABLE KEYS和LOCK TABLES——这样恢复时才不会卡死。
执行后立刻验证guid字段是否被正确更新
很多人只查文章正文，却忘了guid。它是WordPress识别文章唯一性的字段，RSS、导入导出、部分插件都依赖它。如果只改了post_content没动guid，会出现“文章显示正常，但分享到微信/Telegram里点开是404”的诡异问题。
验证方法很简单：
- 在SQL窗口执行：
SELECT ID, guid FROM wp_posts WHERE guid LIKE '%old.com%' LIMIT 5; - 如果返回结果为空，说明已更新成功；如果还有残留，立刻用对应
UPDATE语句补救
最易被忽略的点：有些主题或插件会在wp_postmeta里存自定义URL（比如幻灯片插件的_slide_url），这种没法靠通用SQL覆盖，得单独查字段名再补语句。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
