迁移的难点不在搬数据，在「搬完之后敢不敢切」。

胆量来自数据。而数据可以提前拿到，不用等用户来告诉你。

三类页面，覆盖三种风险

静态首页。风险在证书、在 Web 服务器配置、在静态资源的压缩。这一类最容易通过，也最容易被忽略——因为它太容易通过，反而没人细看 TLS 握手和下载段。

动态接口。风险在数据库连接、缓存预热、应用启动。新环境的 TTFB 往往比老环境差一截，因为缓存是空的。测出来差，未必是故障，但要知道差多少、跑多久能追上。

登录后的页面。风险在会话共享、在权限表、在文件存储路径。这类问题只在带 Cookie 时才暴露，匿名测速永远是 302。

对比的方法

同一条 URL，同一组参数，在 网站测速 里先测新环境，再测老环境。节点范围选同一批，别一个用快速测速一个用全节点，那样比出来没意义。

看三个数：平均响应、最快、最慢。平均值接近但最慢差很多，说明新环境有抖动，可能是资源不足或者网络不稳。

再看五段耗时。哪一段拉开的差距最大，就往哪一层查。这个判断方法比看总耗时靠谱得多。

什么时候这套方法不适用

源站只允许 CDN 回源，或者配了 IP 白名单，指定解析会被拦。这种情况下先申请放行拨测节点，或者临时把测试 IP 加进白名单。

需要 Host 校验的站也一样。拨测发的是域名 Host，一般没问题，但如果源站绑了多个站、靠 Host 分流，得确认打到了正确的那个。

切完之后再做一次

DNS 切完，用全节点跑一遍。这时候测的是真实链路，包括 DNS 生效情况和新机器在各地运营商下的表现。

前面所有准备，都是为了让这一步的结果符合预期。不符合也没关系，至少你知道该回滚还是该修。

顺手用 IP 查询 抽查几个地区的解析结果，确认没有残留的旧记录——TTL 没到期的缓存，是迁移后最常见的幽灵故障。