当前位置：首页 > 文章列表 > 文章 > python教程 > PythonRequests超时设置与重试技巧

PythonRequests超时设置与重试技巧

2026-05-29 22:18:37 0浏览收藏

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

Python使用Requests报Timeout超时怎么办_设置timeout参数与retrying重试库

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
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)
后续所有 session.get() / session.post() 都自动带重试
response = session.get("https://api.example.com/data", timeout=(3, 10))

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

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和上下文，再决定是立即重试、降级返回缓存，还是直接上报告警。