迁移前准备
站点迁移失败的根本原因，大多是准备不足——TTL 没调低、记录没备份、新服务器没验证就切换。正确的迁移，是风险可控的有序切换。
迁移的几种场景
| 场景 | 说明 |
|---|---|
| 服务器迁移 | 同域名，换 IP（从 A 服务器迁到 B 服务器） |
| 平台迁移 | 从 WordPress 迁到 Webflow，从自建迁到 Shopify |
| 域名迁移 | 更换主域名（需要做重定向 + SEO 考虑） |
| DNS 托管迁移 | 把 DNS 从注册商迁到 Cloudflare |
| 注册商迁移 | 把域名从 GoDaddy 迁到 Namecheap |
本章以服务器迁移（同域名换 IP）为核心，其他场景的差异会另行说明。
迁移准备清单
1. 记录所有现有 DNS 记录
导出方式（Cloudflare）： DNS → Advanced → Export（下载 BIND 格式文件）
手动备份（任何 DNS 提供商）：
# 查询所有常用记录类型
dig example.com A
dig example.com AAAA
dig example.com CNAME
dig example.com MX
dig example.com TXT
dig example.com NS
把结果保存到文档，新服务器配置完后对照检查。
2. 提前调低 TTL
在迁移前 24 小时把所有关键 DNS 记录的 TTL 从默认值（3600 或 86400）降低到 300 秒（5 分钟）。
原 TTL: 3600（1 小时）
→ 改为: 300（5 分钟）
→ 等待 1 小时（让旧缓存过期）
→ 再执行迁移切换
为什么要等：即使你把 TTL 改为 300，也要等旧 TTL 过期后（最多 3600 秒）全球解析器才会开始使用新 TTL。
3. 在新服务器完整部署并验证
切换 DNS 之前，新服务器必须已经完全就绪：
- [ ] 代码/应用已部署完成
- [ ] 数据库已迁移并数据一致性验证通过
- [ ] SSL 证书已申请并配置
- [ ] 所有子域名路由配置正确
- [ ] 邮件配置未变动（MX、SPF、DKIM 不需要改）
- [ ] 性能测试通过（用负载测试工具，确认新服务器能承受流量）
4. 用 Hosts 文件提前测试新服务器
在 DNS 切换之前，用本地 hosts 文件把域名指向新 IP，测试新服务器是否正常：
Mac/Linux：
sudo nano /etc/hosts
# 添加：
104.21.3.6 example.com # 新服务器 IP
104.21.3.6 www.example.com
Windows： C:\Windows\System32\drivers\etc\hosts（用管理员权限编辑）
测试完成后记得删除 hosts 文件里的临时记录。
迁移时机选择
| 因素 | 建议 |
|---|---|
| 时间 | 选流量低谷（深夜、周末） |
| 节假日前后 | 避开（有问题没人处理） |
| 促销活动期 | 绝对不要在活动期间迁移 |
| 版本发布后 | 等新代码稳定运行 1–2 周后再迁 |
迁移通知（如有必要）
如果你的服务有 SLA 承诺，或者有企业客户，迁移前要提前通知：
- 邮件告知维护窗口（2026-03-25 02:00–04:00 UTC）
- 状态页更新（如果有）
- 内部团队同步
下一节：零宕机切换策略——DNS 切换的正确时序，如何实现对用户无感知的迁移。