先做CNAME切换并保留旧源站至少一周，随后按文件类型分批刷新缓存，而不是一刀切全量刷新。直接在切换前清空所有缓存，容易导致回源流量激增，把新源站打挂，同时丢失热数据，用户体验断崖式下跌，正确的做法，是把缓存刷新当作一次有计划的流量调度，而不是一次性的“清空重来”。
为什么“切换前全量刷新”是个坑
很多站长在迁移源站前，习惯性地把所有节点缓存全部清空，觉得这样“干净”，但这里有一个被忽视的连锁反应：全量刷新会让所有边缘节点同时失效，而新源站尚未承接完整流量，瞬间的回源压力会集中在迁移后的几小时内，据行业共识，CDN边缘节点的回源能力通常按日常峰值的1.2倍设计，一次性全量刷新造成的回源风暴,足以让绝大多数中等配置的新源站响应超时。
更隐蔽的坑是缓存命中率断崖，一个运营成熟的站点，缓存命中率普遍在90%以上，全量清空意味着90%的请求直接穿透到源站，新源站从冷启动到稳定，缓存重建需要时间,这个过渡期内的首屏加载速度会肉眼可见地变慢。
另一类常见误区是只刷新URL，不刷新目录，实际场景中，很多站点用的是带版本号的静态资源，但首页、栏目页这类URL不带版本号，如果只按URL精确刷新，漏掉目录层级，迁移后会有相当一部分用户访问到旧缓存,造成样式错乱或数据不一致。
正确的迁移缓存处理流程：分阶段操作
标准流程拆成三个阶段,每个阶段解决一个明确问题。
第一阶段：切换前24小时的DNS预调整
在正式切换DNS解析前24小时，先做一次“低风险刷新”，只刷新首页、频道页、热门落地页这三级核心入口，数量控制在总缓存量的5%以内，这一步不是为了让缓存失效，而是让这部分流量提前回源到新源站，验证新源站在真实请求下的响应速度、错误率、证书配置是否正常。
操作路径：在CDN控制台的刷新工具里，选择“URL刷新”，粘贴这几十个核心地址，提交后观察回源状态码，正常情况应为200或304，如果出现502或503，说明新源站存在配置问题，此刻还有时间修,而不是等切换后才知道。
注意事项：这一阶段不要动图片、视频、CSS/JS这类静态资源缓存，它们占比最大,留着能继续分摊旧源站的流量压力。
第二阶段：DNS切换后的分批刷新顺序
DNS解析完全切换后，新源站开始接收全网流量，但节点上还有大量旧缓存，这时刷新的核心逻辑是类型和失效成本排序。
| 优先级 | 文件类型 | 刷新方式 | 原因 |
|---|---|---|---|
| 第一梯队 | HTML页面、接口数据 | 目录刷新 | 用户感知最强，必须即时更新 |
| 第二梯队 | CSS/JS | 按文件名刷新 | 一般带版本号，精确刷新即可 |
| 第三梯队 | 图片、字体 | 批量URL刷新 | 如果未改名，需要全量刷新 |
| 第四梯队 | 视频、大文件 | 不刷新，等自然过期 | 预热成本高，回源压力大 |
为什么要按这个顺序？因为HTML和接口数据失效后，下一次请求回源拿新数据，节点重新缓存，代价最小，而视频文件动辄几百MB，强制失效后全部回源，新源站的带宽会被瞬间吃满，有经验的运维人员会把视频这类大文件的缓存过期时间直接配置为原样保留,等它自然过期。
阶段刷新时的操作路径：在CDN控制台选择“目录刷新”，填入https://www.example.com/，这会刷新主域名下所有HTML页面，但不会动静态资源，随后在“URL刷新”中批量提交带版本号的JS/CSS路径，如果新旧版本号不同，其实刷新也不紧急，因为浏览器和节点都会按新URL回源,旧的让它慢慢淘汰。
第三阶段：预缓存预热，主动填充热点资源
刷新是让缓存失效，预热是让缓存重新建立，刷新完成后，如果放任自流，热点资源要等用户访问才会逐条回源，分布式节点逐台填充，冷启动时间可能长达数小时，分批刷新结束后，需要立刻针对访问量Top 100的资源做预热。
操作方法：从旧源站或CDN日志中导出过去7天访问次数最高的URL列表，在控制台的“预热”功能中批量提交，预热后确认新源站带宽有明显上升，说明节点正在回源拉取，这就对了，预热量控制在总缓存体积的10%以内,避免预热本身造成回源压力。
行业内通常建议，预热后观察一段时间的缓存命中率，如果命中率回升到85%以上,说明迁移的缓存过渡基本完成。
缓存刷新失败的排查与验证方法
刷新提交后，不表示事件结束了，必须主动验证，常用验证手段是curl命令行测试。
curl -I https://www.example.com/
以-I参数只获取HTTP响应头，重点看X-Cache字段或Age字段。X-Cache: HIT表示命中了节点缓存，MISS表示本次请求回源了，如果刷新前是MISS，刷新后仍然是MISS，说明刷新生效，只是节点重新回源拉取了，如果刷新后依然HIT，且Age字段较大,说明刷新指令未生效或提交的URL与实际访问URL不一致。
这里有一个高频坑：URL包含HTTP和HTTPS两种协议头，刷新时必须精确匹配，提交了http://的URL，刷新不了https://的缓存，同样，带不带www、路径结尾带不带,在刷新系统里视为完全不同的资源。
另一个验证维度是新源站访问日志，回源请求的User-Agent通常带有CDN厂商标识，通过过滤这个标识，可以看到回源IP分布和请求量变化，如果刷新后，新源站收到来自某个CDN节点的大量回源请求，且该节点IP在同一个地域段,说明那个节点的缓存确实被清理了。
迁移后的缓存收敛与旧源站回收
迁移后一周内，站点会处于“新旧源站并存”的状态，这不代表旧源站无用，相当一部分用户本地DNS缓存未过期，或者个别CDN节点未完成缓存刷新，仍然会指向旧源站，业内专家指出，DNS解析的全球生效时间最长可达48小时，加上各节点刷新队列的延迟,一周的并存期是比较稳妥的做法。
在此期间，建议每天观察一次回源失败率和新源站流量占比，流量占比超过95%后，可以进入旧源站回收流程：先在旧源站上开启只读模式，保留数据但拒绝新写入，观察三天无异常后,再回收服务器资源。
有一个细节容易被忽略：如果站点原先使用了对象存储作为源站，回收时不要马上删除存储桶，建议先把存储权限改为私有，保留一个月做归档，因为搜索引擎的索引可能还缓存了旧URL,爬虫重访时需要一定的期限才会过期。
源站迁移缓存刷新常见问题
源站迁移时CDN缓存怎么处理才能最大限度减少回源压力？
核心是避免全量刷新，先按目录刷新HTML，再按URL刷新带版本号的静态资源，最后预热Top热点资源，整体原则是让静态资源自然过期,只主动刷新动态内容和核心入口。
为什么刷新后访问还是旧内容？
检查刷新时提交的URL与浏览器访问的URL是否完全一致，包括协议头、域名类型、路径尾部的斜杠，如果一致，则检查CDN控制台的刷新记录，确认状态是“成功”还是“进行中”，还有可能页面本身被浏览器缓存捕获,这时需要强制刷新浏览器缓存。
CDN缓存刷新和预热可以同时进行吗？
可以，但建议分步执行，先刷新核心HT