直接用 time.sleep() + while 循环写重试很危险,因其易忽略退避策略、超时边界和异常分类,导致请求雪崩或长时间卡死;而 tenacity 通过可配置的 retry_if_exception_type、stop_after_attempt/delay、wait_exponential(含 jitter)等机制,实现精准、可控、可观测的重试。

为什么直接用 time.sleep() + while 循环写重试很危险
手动控制重试容易忽略退避策略、超时边界和异常分类,导致请求雪崩或长时间卡死。比如连续 5 次 1 秒后重试,实际是 5 秒密集打接口;又或者把 ConnectionError 和 HTTPError(404) 一视同仁地重试,浪费资源还可能触发风控。
用 tenacity 的核心价值不是“多试几次”,而是让每次重试都可配置、可观察、可终止:
-
retry_if_exception_type可精确指定只对网络类异常重试,跳过业务错误 -
stop_after_attempt和stop_after_delay双重兜底,防止无限循环 -
wait_exponential默认带 jitter,避免重试请求同时到达服务器
tenacity 最简可用的爬虫重试装饰器写法
别一上来就堆参数。先跑通一个能捕获 requests.exceptions.RequestException 并指数退避的版本:
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type import requests <p>@retry( retry=retry_if_exception_type(requests.exceptions.RequestException), stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10) ) def fetch_url(url): return requests.get(url, timeout=5)
注意三个关键点:
立即学习“Python免费学习笔记(深入)”;
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac,无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启:辅助功能 + 屏幕录制权限
-
multiplier=1表示首次等待 1 秒,第二次约 2 秒,第三次约 4 秒(有 jitter 所以不是严格翻倍) -
min=1防止首次等待太短,max=10防止某次退避过长 - 没加
before或after钩子时,失败日志默认不输出——调试阶段建议加上before=before_log(logger, logging.DEBUG)
如何区分“该重试”和“该放弃”的 HTTP 状态码
tenacity 本身不解析响应体,所以不能直接靠 status_code 控制重试。得在函数内部抛出特定异常,再由装饰器捕获:
from requests.exceptions import RequestException
<p>@retry(
retry=retry_if_exception_type((RequestException, ValueError)),
stop=stop_after_attempt(3)
)
def fetch_with_status_check(url):
resp = requests.get(url, timeout=5)
if resp.status_code in (429, 500, 502, 503, 504):
raise ValueError(f"Transient HTTP {resp.status_code}")
elif resp.status_code == 404:
raise ValueError("Not found - don't retry")
return resp
这里的关键逻辑是:
- 把临时性服务端错误(如
502、429)转成统一异常类型,让tenacity捕获并重试 - 把明确不可恢复的错误(如
404)也抛异常,但不在retry_if_exception_type列表里,从而立即终止 - 不要试图在
retry参数里写 lambda 去检查resp.status_code—— 因为装饰器在函数执行前就已绑定,拿不到返回值
生产环境必须加上的两个安全阀
线上爬虫一旦重试失控,轻则被限流,重则 IP 被封。以下两项不是可选项:
- 必须设置
timeout:每个requests调用显式传timeout=(3, 7)(连接 3 秒,读取 7 秒),否则单次请求卡住会拖垮整个重试周期 - 必须限制总耗时:用
stop=stop_after_delay(30)替代纯次数限制,防止在高延迟网络下重试 3 次就耗掉 60 秒
真正难处理的是那些不报错但返回空数据、或返回验证码页面的情况——tenacity 解决不了这类逻辑问题,得靠后续的内容校验环节拦截,而不是指望重试机制兜底。

















