重试逻辑需捕获ConnectionError、Timeout、HTTPError等异常，仅对5xx状态码及网络异常重试，采用指数退避（sleep 2**attempt），最大3～5次；需区分4xx（不重试）与5xx（可重试），响应含Retry-After则优先遵循，避免盲目重试404或反爬页面。
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 的请求只会加速封禁。
- 状态码 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
重试后怎么避免重复采集或漏采？
重试本身不解决幂等性问题。一次请求失败后重试成功，但上游已返回部分数据，下游解析时可能重复入库或跳过有效内容。
立即学习“Python免费学习笔记（深入）”；
- 在发起请求前生成唯一
request_id（如 UUID），记录到日志或数据库，便于事后核对是否真重发 - 对分页接口，不要仅靠 URL 判断是否重试过；应结合参数（如
page=5）+ 时间戳做幂等键 - 如果采集结果要写入数据库，用
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或REPLACE INTO（MySQL）防重复，而不是依赖重试逻辑保证不重复
最常被绕开的细节： 重试过程中如果程序崩溃或被 kill，没记录中间状态，下次启动会从头开始——所以关键任务建议把重试进度落盘（哪怕只是个 JSON 文件），至少记下 URL 和已尝试次数
