CDN回源失败后能否自动重试：先区分请求重放与业务幂等

用户提交申请后看到超时，源站却已经创建了记录。此时再次发送请求，可能解决“没收到结果”的问题，也可能创建第二条申请。设计CDN回源重试时，需要先回答业务是否执行，而不只是连接是否成功。

超时不等于没有执行

按排查需要，可以把故障分为三段：请求尚未到达应用；应用处理后响应未送回；现有证据无法确认结果。第三种状态很常见，应允许客户端查询原操作状态，而不是把所有超时都当作可以重新开始。

MDN对幂等的说明强调，多次相同操作应具有与一次操作相同的预期效果。实际应用仍要遵守方法语义；如果一个GET接口被错误用于创建订单，不能因为方法名是GET就认为重试安全。

给每条业务路径写出重试规则

“接入高防CDN”不会自动赋予业务幂等能力。应用、客户端和代理应共同约定，不能由某一层单独打开一个重试开关就结束设计。

幂等键必须跟随原操作

Stripe的官方接口文档提供了使用幂等键识别重试的实例。不同API对结果保存、失败处理和有效期有不同约定，因此这里只借用设计思路，不把某家的行为当作行业通用规则。

系统应校验同一个键是否对应同一个账号和同一份业务参数，明确并发到达时由谁执行，以及保留窗口结束后如何处理。每次重试都生成新键，会失去关联效果；不同用户共用一个键，又可能混淆结果归属。

多层重试需要总预算

浏览器、SDK、边缘、反向代理及后台任务可能各自重试。如果每层都只看自己的次数，应用收到的总请求会高于用户发起量。交接时画出各层重试条件、最大尝试数和等待范围，保留统一操作标识及每次尝试的独立记录。

对于持续失败，应有退避和停止条件，避免客户端在高峰故障时集中重发。等待预算也要与业务允许的完成时间一致，不能无限增加超时让用户一直挂起。

验收以业务结果为准

在测试环境分别模拟处理前失败、处理后响应中断和重复提交，检查最终记录是否符合预期。测试要使用隔离的业务对象，不对真实付款或生产订单制造不确定状态。

提交给SCDN实施团队的清单应说明哪些路径允许平台重试、哪些必须由应用查询结果。最终成功标准包括没有多余业务记录、用户能恢复查看状态，以及每次尝试都能追溯。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。