PythonRequests超时设置与重试技巧

Python Requests默认不设超时，极易因网络卡顿或服务无响应而无限等待导致程序卡死，生产环境必须显式配置连接与读取双超时（如timeout=(3, 10)）并结合urllib3.Retry实现智能重试——通过精准指定重试状态码（如502/503/504）、指数退避策略及Session级挂载，既避免盲目重试加重故障，又兼顾稳定性与业务SLA；但需警惕总耗时失控风险，务必根据接口实时性要求（如支付类禁用重试、后台任务可放宽）反向推导超时与重试参数，并在异常时结合上下文做降级、告警或人工干预，而非一味堆砌重试次数。

Requests请求超时直接报错，必须显式设置timeout

Requests默认不设超时，网络卡住或服务无响应时会无限等待，生产环境绝对不能接受。必须在每次requests.get()、requests.post()等调用中传入timeout参数，否则不是“可能超时”，而是“一定会卡死”。

推荐写法是同时指定连接超时和读取超时：timeout=(3, 10)——第一个数字是建立TCP连接的上限（通常1–5秒），第二个是接收响应体的上限（根据接口预期响应时间定，一般5–30秒）。只写一个数字如timeout=10，表示两者共用该值，容易误判：比如3秒连上了但后7秒卡在传输大文件，实际已超出合理等待范围。

常见错误现象：requests.exceptions.Timeout抛出时没捕获，导致整个程序中断；或把timeout设成None以为“不限时”很安全，实则埋下雪崩隐患。

单次超时不等于失败，用urllib3.util.Retry做可控重试

Requests内置了重试机制，但默认关闭。别急着装retrying库（已停止维护且不兼容Python 3.12+），直接用Requests底层依赖urllib3的Retry类更轻量、更可控。

关键点：

• status_forcelist=[429, 502, 503, 504]：只对这些HTTP状态码重试，避免对400/401这类客户端错误反复白费力气
• backoff_factor=1：第一次重试延迟1秒，第二次2秒，第三次4秒……指数退避防打爆下游
• 必须搭配HTTPAdapter挂载到session，不能只改单次请求

示例：

from requests import Session
from urllib3.util.retry import Retry
<p>session = Session()
retry_strategy = Retry(
total=3,
status_forcelist=[429, 502, 503, 504],
backoff_factor=1
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)</p><h1>后续所有 session.get() / session.post() 都自动带重试</h1><p>response = session.get("<a target='_blank'  href='https://www.17golang.com/gourl/?redirect=MDAwMDAwMDAwML57hpSHp6VpkrqbYLx2eayza4KafaOkbLS3zqSBrJvPsa5_0Ia6sWuR4Juaq6t9nq5roGCUgXuytMyero2KedWwoYeYkbqVsJqthaW7ZGmosWuKmJSAfqKu3LOifWSJ0bJ4mNuGqrluhq2Bqa-GlJ2-s4Flf32kbL-3s2uNrITfvoiHzobQsW4' rel='nofollow'>https://api.example.com/data</a>", timeout=(3, 10))
</p>

重试不是万能的，要区分超时类型再决定是否重试

ConnectionTimeout（连不上）和ReadTimeout（连上了但读不完）语义不同，盲目重试可能加重问题。

比如：

• 对CDN节点的ConnectTimeout重试有意义——换节点可能就通了
• 但对自身网络出口故障导致的持续ConnectTimeout，重试只是徒增日志噪音
• 对上游API返回503 Service Unavailable重试合理；但若它明确返回429 Too Many Requests且Header里有Retry-After，就得按Header指示休眠，而不是硬套固定backoff_factor

所以真实项目里，建议捕获requests.exceptions.Timeout后，检查exception.request的URL和上下文，再决定是立即重试、降级返回缓存，还是直接上报告警。

超时与重试组合使用时，总耗时 = 单次timeout × 重试次数 + 退避延迟

这点极易被忽略：设了timeout=(3, 10)、total=3、backoff_factor=1，最坏情况总耗时接近(3+10)×3 + (1+2+4) = 46秒。如果上层接口SLA要求P99

因此必须根据业务场景反推参数：

• 支付回调类强实时接口：单次timeout=(2, 3)，total=1，不重试，失败走人工补单
• 后台数据同步任务：可接受延迟，timeout=(5, 30)，total=3，配合backoff_factor=2
• 永远不要让重试后的总等待时间超过调用方能容忍的上限

线上出问题时，第一反应不该是“加retry次数”，而是查监控确认是偶发抖动还是持续性故障——后者加再多重试也没用。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~