Python调用接口超时很常见，关键不是避免超时，而是让程序在超时后能自动恢复、不中断、不丢数据。核心思路是：设置合理超时 + 捕获异常 + 有策略重试 + 避免雪崩。
明确超时类型，分别控制
HTTP请求通常涉及两个超时：连接超时（connect timeout）和读取超时（read timeout）。连接超时指建立TCP连接的时间上限，读取超时指等待服务器返回响应体的时间上限。Requests库中用 timeout=(3, 10) 表示“3秒连不上就放弃，连上后最多等10秒收完数据”。建议设为元组而非单值，避免长时间卡死在慢响应上。
用 requests.adapters.HTTPAdapter 配置重试策略
Requests内置的重试机制需手动启用，推荐通过 Session + Adapter 统一管理：
- 使用 urllib3.Retry 定制重试次数、状态码、后退因子（backoff_factor）
- 对 5xx 和部分 4xx（如 429）重试，但跳过 400、401、403、404 等客户端错误
- 启用 backoff_factor 实现指数退避，例如 factor=1 时，重试间隔依次为 1s、2s、4s、8s
- 注意：默认不重试 POST/PUT 等非幂等请求，若业务确定安全，可设 allowed_methods=False 或显式指定方法列表
封装带上下文感知的请求函数
单纯依赖 Adapter 不够灵活，实际中常需按接口重要性、失败原因、当前负载动态调整行为：
立即学习“Python免费学习笔记（深入）”；
- 对核心支付接口，允许最多3次重试 + 逐次延长超时（如 (3,5) → (5,8) → (8,12)）
- 对第三方天气API，失败后降级为缓存数据，不重试
- 加入简单熔断：连续5次超时，暂停该接口调用60秒，用内存变量或 Redis 记录状态
- 记录每次重试的耗时、状态码、异常类型，便于后续分析瓶颈（比如全是 ReadTimeout，说明服务端处理慢）
避免重试引发的新问题
重试不是万能解药，滥用反而加重故障：
- 不要对 POST 创建订单 类非幂等操作盲目重试，可能造成重复下单；应先查单再决定是否重试，或依赖服务端幂等键
- 高并发下大量重试会放大流量，压垮下游；建议加随机抖动（jitter），比如 base_delay * (1 + random(0, 0.3)）
- 异步任务中重试要持久化状态，防止进程重启后丢失重试计数；Celery 可用 autoretry_for + retry_kwargs
- 日志中清晰标记“第X次重试”，避免排查时混淆原始失败和重试失败
不复杂但容易忽略。超时和重试不是写一次就完事的配置，而是需要结合业务语义、依赖稳定性、监控反馈持续调优的行为模式。
