requests.Session()配合urllib3.Retry可精准控制重试：需创建Retry策略（如total=3、status_forcelist=[429,500,502,503,504]、backoff_factor=1）、绑定HTTPAdapter并挂载到Session，使所有请求自动启用连接层重试，避免手动循环或单次调用失效。
requests.Session() 配合 urllib3 的 Retry 对象最直接
Python 标准库 requests 本身不内置重试逻辑，但底层依赖的 urllib3 提供了 urllib3.util.retry.Retry 类，配合 requests.Session() 就能精准控制重试行为。关键不是“加个装饰器”或“套个 while 循环”，而是把重试策略绑定到连接池层面，避免重复创建连接、遗漏重定向或状态码判断。
常见错误是直接对 requests.get() 单次调用包 try-except + sleep，这无法处理连接建立失败（如 DNS 解析超时）、TCP 握手失败等底层错误，且容易漏掉 5xx 响应的重试场景。
-
Retry默认只对连接错误和读取错误重试，不包含 4xx 响应（比如 429 Too Many Requests），需要显式设置status_forcelist=[429, 500, 502, 503, 504] - 重试间隔建议用指数退避：
backoff_factor=1表示第 1 次重试等待 1s，第 2 次 2s，第 3 次 4s，依此类推 - 务必限制最大重试次数（如
total=3），否则可能卡死在持续失败的请求上
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
<p>session = requests.Session()
retry_strategy = Retry(
total=3,
status_forcelist=[429, 500, 502, 503, 504],
backoff_factor=1,
allowed_methods=["HEAD", "GET", "OPTIONS"] # 注意：requests 2.26+ 用 allowed_methods，旧版用 method_whitelist
)
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 href="https://www.php.cn/link/b05edd78c294dcf6d960190bf5bde635">https://www.php.cn/link/b05edd78c294dcf6d960190bf5bde635</a>")
scrapy 中启用 retry middleware 要改 settings.py 和中间件参数
Scrapy 自带 RetryMiddleware，但默认只对 500、502、503、504 和部分连接异常生效，对 429、超时、DNS 失败等不敏感。必须手动调整配置才能覆盖真实爬虫中高频出现的偶发问题。
典型误区是以为开了 RETRY_ENABLED = True 就万事大吉，其实它默认 RETRY_TIMES = 2，且不重试 429 —— 而现在很多反爬接口一过频控就返回 429，不加这个就直接放弃。
立即学习“Python免费学习笔记（深入）”；
- 在
settings.py中添加：RETRY_HTTP_CODES = [500, 502, 503, 504, 429] - 设
RETRY_TIMES = 3，避免两次重试后仍失败（网络抖动有时要三次才恢复） - 如果目标站点 DNS 不稳，可配合
DOWNLOAD_TIMEOUT = 15和RETRY_DELAY = 1（单位秒，非指数退避） - 注意：该 middleware 在
DOWNLOADER_MIDDLEWARES中默认开启，无需额外启用，改参数即可
异步爬虫（aiohttp）得自己封装 retry 逻辑
aiohttp 没有内置重试机制，也不能直接复用 urllib3 的 Retry。必须手动用 asyncio.sleep() + 循环 + 异常捕获来实现，而且要区分不同异常类型：连接类异常（aiohttp.ClientConnectorError）、超时（asyncio.TimeoutError、aiohttp.ServerTimeoutError）、HTTP 状态码（如 503、429）。
容易踩的坑是把所有异常一锅端进 except Exception，结果连 KeyboardInterrupt 或 JSON 解析错误都被重试，导致 Ctrl+C 失效或数据错乱。
- 只捕获明确的网络层异常：
aiohttp.ClientError（父类）、asyncio.TimeoutError - 对响应做状态码检查，手动 raise 异常触发重试，例如：
if resp.status in (429, 503): raise aiohttp.ClientResponseError(...) - 用
random.uniform(0.5, 1.5)给退避加点 jitter，防并发请求集体撞上重试窗口
重试不是万能的，别掩盖根本问题
Retry 只能缓解偶发波动，不能替代合理的请求节流、User-Agent 轮换、会话管理或代理池建设。比如连续收到 429，大概率是频率超标，此时重试只会加重封禁风险；DNS 失败频繁发生，说明本地解析环境或目标域名有问题，不是重试能解决的。
真正容易被忽略的是日志和监控：没记录每次重试的原始错误类型、URL、耗时、最终是否成功，就等于盲操作。至少要在重试前打一条 warn 日志，包含 url、exception、attempt，否则出问题时根本分不清是网络抖动还是接口逻辑变更。
