本文约 2,639 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：备案要等二十天，项目下周就要上线
现实中的矛盾很简单：国内服务器必须备案才能解析过去，而备案需要时间；业务部门不可能等。于是大多数人会先找一台境外服务器应急。问题在于临时方案往往变成长期方案：半年后还是那台机器，国内访问慢得令人尴尬；或者迁移时域名替换没做干净，图片全部失效、后台登录跳转回旧地址。决定成败的不是选哪台临时机器，而是”当初有没有按可迁移的标准来建设”。
原理分析：临时方案的三个约束条件
第一，访问速度要有心理预期。境外节点到国内的链路延迟通常在 100ms 以上且波动大，高峰期丢包更明显；用 Cloudflare 之类全球 CDN 需要注意它在境内并没有自建节点、回源路径受限，提速效果不可一概而论，应以实测为准。
第二，内容与数据必须可整体搬走。WordPress 的绝对 URL 会写进数据库（guid、post_content 里的图片链接、siteurl/home 选项），所以搬家时必须做序列化安全的域名替换——这就是为什么要用 WP-CLI 的 wp search-replace，而不是在数据库里用 SQL 的 REPLACE()。
第三，不要把临时环境当成生产环境长期依赖。上线前应明确：域名所有权一致、数据库可完整导出、媒体目录同步机制确定、以及 DNS 记录的 TTL 已提前调低。
| 环节 | 风险 | 处理 |
|---|---|---|
| 访问速度 | 国内延迟高 | 压缩资源、减少外部请求 |
| 数据迁移 | 序列化破坏 | 用 WP-CLI 替换而非 SQL |
| 切换丢更新 | 迁移窗口期有新内容 | 先只读维护再切换 |
| SEO | 临时域名被收录 | 临时站 noindex 或用正式域名 |
保姆级实操
步骤 1：正式域名第一时间解析到临时服务器。 这是最容易做错的一步：不要用一个新的临时域名上线，否则过段时间会有一批该域名的收录页。正确做法是正式域名先解析到境外服务器，但 robots/HTTP 头先不屏蔽（若希望先占住索引），或反之临时阶段整体 noindex 再在切换时放开。两种都行，关键是决策明确。
步骤 2：提前调低 DNS TTL。 备案通过当天再改 TTL 就没意义了（TTL 决定记录缓存时长）。建议提前把 A 记录 TTL 调至 300 秒：
example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN CNAME example.com.
步骤 3：境内服务器准备完毕。 拿到备案号后，先把正式环境的 Web、PHP、数据库搭建好并完成验证，不要先切 DNS 再装机。
步骤 4：整体迁移。 文件用 rsync，数据库用 mysqldump：
# 静态文件同步（先跑一次全量，正式切换前再增量一次）
rsync -avz --delete /var/www/html/ user@new:/var/www/html/
# 数据库导出与新节点导入
mysqldump -uroot -p --single-transaction --quick old_db | gzip > old.sql.gz
zcat old.sql.gz | mysql -uroot -p new_db
步骤 5：序列化安全的域名替换。 WP-CLI 的 search-replace 能正确处理 PHP 序列化数据，一定要先 --dry-run 看命中数：
wp search-replace 'https://example.com' 'https://example.com' --all-tables --dry-run --skip-columns=guid
wp search-replace 'http://tmp.example.com' 'https://example.com' --all-tables --skip-columns=guid
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
wp rewrite flush
wp cache flush
注意 --skip-columns=guid 是常见做法：guid 是历史 UID，不影响前台展示，留着也无害；若源与目标协议不同（http→https），需要把协议差异也一并替换。
步骤 6：设置只读窗再切换。 正式切换前把临时站设为只读（例如把评论关闭、开启维护模式），完成最后一次 rsync 与导入后再改 DNS、再放开写入，避免切换期间产生的数据差。
步骤 7：验证与清 DNS。 切换后用 dig 看记录是否已生效，并检查前台/后台、图片、表单、证书：
dig +short example.com @223.5.5.5
curl -I https://example.com | head -5
常见踩坑
- 临时站用了新域名，正式域名长期闲置，最后正式站要从零积累。
- 案例： 某项目迁移时直接在 phpMyAdmin 里执行 SQL 的 REPLACE 替换域名，破坏了 wp_options 与部分 widget 的序列化长度，导致后台菜单、小工具全部消失，只能从备份回滚。
- 忘了
--dry-run，实际替换后发现某些表（如外部统计表）被误改。 - 没提前调低 TTL，DNS 生效等了整整一天，期间用户被随机分到新旧两台机器。
- 迁移后忘了刷新固定链接，
wp-admin出现 404 循环。 - 证书只配了旧域名或漏了 www，切换后部分用户看到证书告警。
- 临时站 与正式站同时可写，导致两边数据分叉，最后无法判断哪边是最新版本。WordPress 站点迁移完整流程
总结
判断这套临时方案是否成功的标准是：迁移当天是否能在半小时内完成切换、数据是否无损、以及临时环境是否最终被彻底停用。行动清单：正式域名先上线 + TTL 提前降到 300 → 境内环境先备好 → rsync + mysqldump → wp search-replace 带 dry-run → 只读窗内完成最后一次同步 → 切换后逐功能验证。把”临时”两个字刻在流程里，就不会让它悄悄变成常态。迁移后的搜索表现保全措施见 WordPress 301 重定向处理。
