接口调用失败需策略性重试：只重试可恢复错误（如超时、502/503/504），避免重试4xx等无效错误；采用指数退避+随机抖动、限制3～5次重试；结合熔断、超时控制与日志记录提升可观测性与稳定性。
接口调用失败很常见，重试不是简单地“再试一次”，而是要有策略地应对不同错误类型、避免雪崩、兼顾效率与稳定性。
区分错误类型，只重试可恢复的异常
网络超时、连接拒绝、502/503/504 等临时性错误适合重试；而 400（参数错误）、401（鉴权失败）、404（资源不存在）或 500（服务端逻辑错误）通常重试无效，应直接失败并记录。
- 用 requests 库时，检查 response.status_code 和 exception 类型（如 requests.exceptions.Timeout、ConnectionError）
- 封装请求函数时，显式定义 retryable_errors = (Timeout, ConnectionError, HTTPError with 502/503/504)
- 对非重试错误，尽早抛出或返回明确结果，避免无意义循环
采用指数退避 + 随机抖动，防止请求洪峰
固定间隔重试容易造成下游服务瞬时压力激增；指数退避让等待时间逐次增长，叠加随机抖动可进一步分散请求时间点。
- 基础等待时间：1s → 2s → 4s → 8s（2ⁿ⁻¹ 秒）
- 加入抖动：每次等待在 [base * (1 - jitter), base * (1 + jitter)] 区间内随机取值（如 jitter=0.2）
- 推荐最大重试次数为 3～5 次，避免长尾延迟拖累整体响应
设置全局熔断与上下文感知超时
连续失败达到阈值时，主动熔断一段时间，跳过重试直接失败，保护下游和自身资源；同时确保每次请求本身有合理 timeout（connect + read），避免单次卡死阻塞重试流程。
立即学习“Python免费学习笔记（深入）”；
- 使用 tenacity 库可方便实现熔断（
stop=stop_after_attempt(3),wait=wait_exponential(multiplier=1, min=1, max=10) + wait_random(0, 1)） - requests 调用必须指定 timeout=(3, 10)（3秒连通，10秒读取），不设 timeout 等同于无限等待
- 业务关键接口可结合调用方上下文（如用户操作是否允许等待）动态调整重试次数或超时
记录重试行为，便于问题定位与容量评估
重试本身是故障信号。不记录就等于放弃可观测性——无法判断是偶发抖动还是系统性降级。
- 每次重试前打日志，包含：接口路径、原始错误、重试次数、下次等待时间
- 统计维度建议：按接口、错误码、重试成功率、平均重试耗时做聚合
- 告警可基于“5分钟内某接口重试率 > 20%”或“单次重试耗时 > 30s”触发
重试不是兜底银弹，而是稳定性工程中精细调控的一环。设计得当能显著提升可用性，滥用反而放大风险。
