如何利用Python编写健壮的爬虫异常重试机制提升采集成功率？-Python教程-PHP中文网

重试逻辑需捕获connectionerror、timeout、httperror等异常，仅对5xx状态码及网络异常重试，采用指数退避（sleep 2**attempt），最大3～5次；需区分4xx（不重试）与5xx（可重试），响应含retry-after则优先遵循，避免盲目重试404或反爬页面。

如何利用python编写健壮的爬虫异常重试机制提升采集成功率？

requests 请求失败时怎么加重试逻辑？

直接用 requests.get() 发请求，遇到网络抖动或目标服务器临时拒绝就崩，必须自己兜底。核心是捕获异常、判断是否值得重试、控制重试次数和间隔。

捕获的异常不止 requests.exceptions.ConnectionError，还要包括 requests.exceptions.Timeout、requests.exceptions.HTTPError（比如 5xx）、以及 requests.exceptions.RequestException 作为兜底父类
不要对 404 或 403 自动重试——这是业务状态，不是临时故障
推荐用指数退避：time.sleep(2 ** attempt)，避免瞬间重试压垮自己或对方
最大重试次数建议设为 3～5，再高意义不大，反而拖慢整体采集节奏

import time
import requests
<p>def fetch_with_retry(url, max_retries=3):
for i in range(max_retries + 1):
try:
resp = requests.get(url, timeout=10)
resp.raise_for_status()  # 抛出 4xx/5xx
return resp
except (requests.exceptions.ConnectionError,
requests.exceptions.Timeout,
requests.exceptions.HTTPError) as e:
if i == max_retries:
raise e
time.sleep(2 ** i)</p>

怎么区分该重试还是该跳过？

不是所有失败都适合重试。盲目重试 404 页面会浪费资源，反复重试被封 IP 的请求只会加速封禁。

提示词大师-python版

图片提示词生成器？不止如此。马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。输入「新手指南」查看完整功能介绍

下载

状态码 500、502、503、504 属于服务端临时错误，可重试；400、401、403、404 多数是客户端问题或权限限制，不建议重试
如果响应头含 Retry-After，优先按它给的时间休眠，而不是硬套指数退避
检查 resp.headers.get("Content-Type") 是否为空或非 text/html，可能是反爬返回的空页或 JS 渲染页，这种重试没用，得换策略（如加 headers 或切浏览器）

常见误判场景： - 把 requests.exceptions.TooManyRedirects 当成网络问题重试（实际是重定向循环，应终止） - 对带验证码的 403 响应持续重试（应该记录并人工介入） - 未检查 resp.content 长度，重试后拿到的是 1KB 的“请启用 JavaScript”页面，误以为成功

多线程/异步环境下重试怎么不互相干扰？

用全局重试计数器或共享锁会串行化请求，失去并发意义。每个请求必须独立管理自己的重试状态。

不要用模块级变量存重试次数，每个请求实例应携带自己的 attempt 计数
在 concurrent.futures.ThreadPoolExecutor 中，闭包或参数传入重试配置即可，无需额外同步
异步场景（aiohttp）更要注意：不要在协程里用 time.sleep()，改用 await asyncio.sleep(2 ** attempt)
如果用 retrying 或 tenacity 库，确认其装饰器支持异步函数（tenacity 的 @retry 支持 coroutine，retrying 不支持）

容易忽略的一点：重试时若修改了请求参数（比如换 User-Agent），必须确保新参数只作用于当前重试轮次，不能污染原始请求对象——否则后续其他请求可能意外带上调试用的 UA

重试后怎么避免重复采集或漏采？

重试本身不解决幂等性问题。一次请求失败后重试成功，但上游已返回部分数据，下游解析时可能重复入库或跳过有效内容。

在发起请求前生成唯一 request_id（如 UUID），记录到日志或数据库，便于事后核对是否真重发
对分页接口，不要仅靠 URL 判断是否重试过；应结合参数（如 page=5）+ 时间戳做幂等键
如果采集结果要写入数据库，用 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或 REPLACE INTO（MySQL）防重复，而不是依赖重试逻辑保证不重复

最常被绕开的细节：重试过程中如果程序崩溃或被 kill，没记录中间状态，下次启动会从头开始——所以关键任务建议把重试进度落盘（哪怕只是个 JSON 文件），至少记下 URL 和已尝试次数