域名替换应先限定表、列和实际网址形式，用dry-run查看预计改动，再处理序列化数据并核对结果。GUID用于内容标识，通常不应当作普通访问链接批量改写；发现旧域名字符串也不等于迁移失败。
先定义需要替换的访问数据
记录旧新域名、协议、www形式与测试环境差异，区分正文链接、配置、缓存数据和标识字段。多站共库时必须确认当前表前缀及作用范围。不要一开始就对数据库里所有表、所有字符串做全局替换。
先用试运行报告证明范围
WP-CLI search-replace支持dry-run，可先报告预计替换而不落库。结合表和列限制、序列化数据处理与必要的skip-columns参数制定命令。示例命令应换成测试环境中的真实目标，密码和客户数据不要出现在公开日志。
GUID不是待修复链接清单
GUID是内容持久标识，许多迁移场景会跳过guid列，避免阅读器等将既有内容误认成新条目。是否出现旧域名应按字段用途解释，不能为了实现全文搜索零命中就把所有标识改成新域名。
正式替换后检查业务和残留来源
在已验证可恢复的数据库副本基础上执行，保存运行结果。重新检查媒体、页面构建器数据、登录、表单及下载入口；再分类解释残留旧域名，是仍应修复的访问地址、历史内容还是需要保留的标识。
关键区别
访问链接：需要指向正确站点；按协议和域名核对。
序列化数据：使用兼容处理方式；不能只做普通文本SQL。
GUID字段：保持内容标识稳定；通常不作为链接替换。
怎样确认处理到位
已确认的访问链接进入正确站点，序列化资料可正常读取，旧域名残留都有字段级解释，未影响其他站点数据。
容易误判的边界
试运行结果不等于已完成替换；备份文件存在也不等于已经验证恢复。生产执行前应明确回退方式。
