API遇到429或超时怎么办？限流、重试与退避策略
先区分拒绝、失败与结果未知
429表示请求受到速率限制，响应可能通过Retry-After提供等待提示；客户端应结合接口文档处理，而不是立即加大并发。相关状态码定义见RFC 6585。
超时则更复杂。请求可能没有到达服务器，也可能已经执行成功，只是响应没有返回。因此，“客户端报错”不能自动推导为“服务器没有做这件事”。创建订单、分配资源和发送通知等操作，重复提交可能产生额外副作用。
参数错误、认证失败和明确的业务拒绝通常需要修正原因，不应无限重试。服务临时不可用是否可重试，也应由接口契约和操作语义决定，不能只按所有五百段状态码统一处理。
设置整个操作的时间预算
客户端需要连接超时、单次请求超时和整个逻辑操作的总时限。重试次数有限但每次等待很长，仍可能让用户等待过久；反过来，过短超时会把正常的稍慢请求变成大量失败和重试。
假设用户操作允许等待二十秒，应把请求和等待都包含在这二十秒内，而不是每次重试重新获得二十秒。总时间耗尽后返回明确状态，并保留后续查询或人工处理方式。
AWS可靠性文档建议控制重试调用，避免在系统承压时由重试放大负载。尤其多层服务都自动重试时，最终调用次数可能远多于最外层看到的次数。官方重试建议
退避与随机扰动减少同步冲击
对适合重试的临时错误，可以采用逐步增加等待时间并设置上限的策略。若所有客户端使用相同固定节奏，它们可能在同一时刻再次集中请求；加入随机扰动可以分散这种同步。
AWS对指数退避与随机扰动的分析说明了这一点。具体初始等待、上限和最大次数仍应按接口限制、延迟目标和并发规模选择，不能把示例数字当作所有系统的默认最佳值。AWS官方分析
如果响应提供有效的等待提示，应按接口约定尊重它，同时考虑总操作时限。不要通过轮换账号、地址或凭据绕开服务方限流；需要更多容量时应调整调用模式、合并请求或申请合适额度。
幂等设计处理已经执行的可能性
对于存在副作用的操作，应优先使用服务方明确支持的幂等机制。为同一个逻辑操作生成稳定标识，重试时复用同一标识，并保持请求语义一致。每次重试都生成新标识，会失去去重作用。
还要核对标识的有效期、作用范围和冲突处理。接口可能只在一定窗口内保存结果，也可能要求同一标识不能配不同参数。客户端应持久保存操作状态，避免进程重启后把同一任务当成新任务再次执行。
如果接口没有提供可靠的去重能力，超时后可以先按业务标识查询结果，确认不存在后再根据契约处理。结果仍不确定时应进入待核对状态，而不是假装失败已被安全解决。
验证重试行为本身
在测试环境模拟429、连接中断、响应延迟和服务恢复，观察实际调用次数、等待间隔和最终业务记录。重点检查用户只操作一次时，系统是否只产生预期的一次业务结果。
记录重试原因、次数、总耗时和最终状态，但不要把认证令牌写入日志。监控应区分首次失败率与重试后成功率；后者看起来正常时，前者持续上升仍可能说明服务压力正在增加。
最终策略应能说明何时重试、等多久、什么时候停止，以及结果未知时由谁处理。这样重试才是恢复短暂故障的工具，而不会成为制造额外负载和重复操作的来源。