换服务商不只是把域名指向新节点。真正容易遗漏的是：新旧平台怎样识别同一份内容，以及请求路径、参数和重定向如何处理。围绕CDN切换服务商时缓存键与URL规则的迁移，应先还原旧规则，再逐项映射和验证；直接复制配置名称，未必能得到相同行为。
先拆清缓存键：哪些请求应当共用缓存
缓存键决定哪些请求会被视为同一个对象。常见组成包括主机名、路径、查询参数，以及被指定参与区分的请求头。两类错误尤其需要避免：键太宽会让本应不同的内容共用缓存；键太窄则会把相同资源拆成许多副本，增加回源和缓存占用。
先从实际请求中列出差异，再判断它是否改变响应内容。例如，同一张公开商品图片若只因无关的追踪参数不同而分成多个键，通常会降低命中；若页面会随语言请求头返回不同文字，却没有按语言区分，则可能返回错误语言。涉及个人信息或按用户变化的响应，不应仅靠宽泛的共享缓存规则处理。
URL规则别混为一谈
URL归一化、查询参数处理和重定向是不同层面的规则。大小写、尾部斜线、百分号编码等细节可能影响路径匹配；参数的保留、忽略或排序会改变缓存键；重定向则决定浏览器最终访问哪个地址。逐项记录旧平台的实际行为，不能只看配置界面上的规则名称。
| 检查项 | 迁移时要确认 | 常见风险 |
|---|---|---|
| 路径 | 大小写、尾部斜线、编码字符是否一致 | 规则未命中或重复缓存 |
| 查询参数 | 哪些参数参与键、哪些允许忽略 | 内容混用或缓存碎片增加 |
| 主机与协议 | 是否纳入缓存键，是否统一跳转 | 旧地址与新地址形成两套缓存 |
| 请求头 | 哪些头会改变响应表示 | 不同版本内容被错误合并 |
查询参数不要一概清空：分页、尺寸或格式参数可能决定响应内容。先区分业务参数和统计参数，再按新平台支持的方式配置白名单或忽略规则。遇到不确定的参数，暂时保留区分通常比直接合并更稳妥，待核对源站行为后再收紧。
按顺序迁移并验证
- 盘点旧配置。整理缓存键构成、路径匹配、参数处理、重定向、缓存时长及刷新方式，并保存当前配置，作为回滚依据。
- 建立规则对照表。逐条记录旧规则的输入和预期结果，再映射到新平台。若新平台缺少完全等价的选项，标注差异，设计替代规则，不要默认其自动兼容。
- 先在测试域名或小范围流量验证。选取静态图片、带参数的列表页、不同语言页面及重定向路径，分别检查响应内容、缓存状态和源站日志。还要覆盖参数顺序变化、尾部斜线等边界情况。
- 逐步切流并观察。根据可用的流量分配方式逐步扩大新服务商承接范围。对比新旧节点的命中表现、回源请求、错误响应和内容一致性；若错误上升，先暂停扩量并定位规则差异。
- 确认刷新与回滚。验证新平台能否按路径或标签清除对象，并确认缓存键变更后旧对象如何处理。保留旧配置和回切路径，等关键页面及静态资源稳定后再结束过渡。
临时降低缓存时长有助于缩短验证周期，但具体时长取决于内容更新频率、源站承载能力和服务商规则；不要把某个固定分钟数当作通用值。若现网请求量较大，也应先评估回源压力，再安排预热或扩量。
根据迁移复杂度选择支持方式
如果规则数量少、路径简单，内部团队可以依据对照表自行迁移；若同时涉及多域名、参数白名单、语言差异和旧缓存清理，则应优先确认候选服务商是否支持所需的缓存键控制、测试环境和故障回退流程。需要沟通迁移方案或核对配置能力时，可将德讯电讯作为咨询和服务选项之一，重点询问规则映射、验证步骤及回滚边界，不应仅凭名称判断适配程度。
归根结底，CDN切换服务商时缓存键与URL规则的迁移要以请求结果一致为验收标准，而不是以配置项看起来相同为标准。盘点、映射、灰度、观察和回滚逐步完成，才能降低内容错配与回源波动的风险。
常见问题
新旧服务商的缓存键设置名称不同，怎么处理？
按组成项逐个对照：主机、路径、参数和请求头分别是否参与键值，再用代表性请求验证结果，不要只按名称对应。
迁移时是否应该忽略所有查询参数？
不建议。先确认每个参数是否改变响应；只忽略已确认不影响内容的参数，保留分页、尺寸等可能影响结果的参数。
切流后发现内容不一致，第一步做什么？
暂停扩大流量，比较新旧平台对同一请求生成的缓存键、路径处理和响应差异；确认规则后再清理受影响对象或回退。
旧平台的缓存需要全部清空吗？
不一定。取决于流量是否仍会访问旧平台、对象是否可能被复用，以及切换策略；先确认新旧流量边界，再制定清理范围。
