Windows
macOS
Android
iOS
接口频繁超时时，盲目增加重试次数往往会让问题更严重：原本已经拥堵的服务会收到更多重复请求，最终形成重试风暴。合理的应用请求超时重试策略，应先判断超时发生在哪里，再决定是否重试、等待多久以及最多尝试几次。
先区分超时类型，再决定处理方式
一次请求通常包含连接建立、发送请求、等待响应和读取响应内容几个阶段。连接超时可能表示网络路径或服务端口不可达；读取超时则可能是服务已接收请求，但处理时间超过预期。两者都显示为“超时”，处理方法却不完全相同。
- 连接超时：可考虑快速重试，但应先确认目标地址、网络访问规则和服务实例是否正常。
- 读取超时：不能直接判定服务没有执行。尤其是创建订单、扣款或提交任务时，服务端可能已经完成操作，客户端只是没有及时收到响应。
- 客户端总超时：它限制整次调用的最大耗时，必须覆盖连接、等待、重试和响应读取，不能只设置单次请求的等待时间。
建议把超时拆成“连接超时、响应等待超时、总超时”三个指标记录。这样可以判断是网络建立慢、后端处理慢，还是重试本身耗尽了时间。
按照请求语义划分可重试范围
查询类请求适合有限重试
读取商品详情、查询库存状态或获取配置等请求通常不会改变服务端数据，遇到网络错误、连接失败或部分网关返回的暂时性错误时，可以进行有限次数重试。不过，仍应排除参数错误、权限不足和资源不存在等明确失败。
写入类请求必须先保证幂等
创建订单、提交表单、发起转账等操作，不能仅因为客户端没有收到响应就再次发送。可使用业务幂等键：客户端为同一业务操作生成唯一标识，服务端保存处理结果；重复请求到达时，服务端返回原结果，而不是再次执行。
如果接口不支持幂等机制，应用请求超时重试策略应对写入操作保持保守，通常只在能够明确确认“请求未到达服务端”时重试。对于支付等高风险场景，还应优先调用订单查询接口确认最终状态。
用总耗时预算控制重试次数
重试次数不是越多越好。应先确定调用方能够接受的总等待时间，再分配给单次尝试和退避等待。例如，一个面向用户的普通查询可以把总预算设在约1至3秒；后台任务可以允许更长时间，但仍应受到任务截止时间限制。实际范围会受到网络距离、服务处理时间和客户端类型影响。
- 先设定总超时预算，例如不超过调用方的业务截止时间。
- 预留日志、序列化和响应读取的时间，不能把预算全部用于网络等待。
- 为每次尝试设置单独的连接和读取上限。
- 当剩余预算不足以完成下一次完整请求时，立即结束重试。
例如总预算为2秒时，第一次请求已经消耗约1.2秒，即使理论上还允许再次尝试，也要判断剩余时间是否足够完成连接和读取。比起固定重试三次，这种“预算驱动”的方式更不容易拖慢上游调用链。
选择退避算法，避免集中再次请求
固定间隔重试容易造成同时发起的请求在同一时刻再次冲击服务。更稳妥的做法是使用指数退避，让等待时间逐步增加，并加入随机抖动。
- 固定间隔：实现简单，适合低流量、内部工具等场景；缺点是容易产生同步重试。
- 指数退避：每次等待时间增加，适合服务暂时过载或依赖方抖动的情况；缺点是延迟可能快速变长。
- 指数退避加随机抖动：在等待区间内随机选择时间，能够分散并发客户端的重试时刻，通常是生产环境更稳妥的选择。
实际配置可从较短的初始等待开始，并设置最大退避上限；面向用户的请求通常只允许少量快速重试，后台任务则可以采用更长退避。若服务返回明确的重试提示，应在不超过总超时预算的前提下参考该提示，而不是完全采用本地固定值。
把重试和熔断、限流配套使用
单独增加重试会掩盖依赖服务变慢的问题。应用还应设置熔断和限流：当一段时间内超时比例持续升高时，暂时停止向故障依赖发起新请求；恢复探测成功后再逐步放量。
同时限制单个请求可产生的最大重试次数，并区分业务线程池。查询接口大量超时时，不应占满处理支付、登录或消息确认的线程资源。对于批量任务，可以把失败记录放入消息队列，按退避规则异步补偿，而不是让前台请求一直等待。
落地实施与验证步骤
- 统计一段时间内的连接超时、读取超时、网关错误和业务错误，先确认主要故障类型。
- 为每个接口标注“只读、可幂等写入、不可安全重试”三类属性。
- 配置单次超时、总超时、最大尝试次数和退避上限，并把这些参数纳入配置管理。
- 记录请求标识、尝试次数、每次耗时、最终状态和依赖服务名称，但避免在日志中写入密码、令牌等敏感信息。
- 在测试环境模拟延迟、连接失败、响应丢失和服务恢复，验证重复请求不会产生重复业务结果。
- 上线后观察超时率、重试率、成功率、平均延迟和下游负载；如果重试率上升而成功率没有改善，应减少重试并排查根因。
常见问题
超时就应该重试吗？
不应该。查询类请求通常更适合重试；写入类请求必须先确认幂等性和业务风险。
重试几次比较合适？
没有适用于所有接口的固定次数。面向用户的调用通常采用少量尝试，后台任务可在更长时间预算内补偿，关键是不能突破总超时。
为什么需要随机抖动？
它能避免大量客户端在相同等待时间后同时重试，从而降低瞬时流量峰值。
如何判断重试是否有效？
同时观察重试后的成功率、额外延迟和下游负载。若成功率不升反降，说明重试可能正在放大故障。
最终，可靠的应用请求超时重试策略不是简单地“失败再发一次”，而是把请求语义、幂等设计、超时预算、指数退避、熔断限流和监控验证组合起来，在可接受的延迟内提高成功概率。