Python爬虫重试技巧：装饰器实现异常重试

本文深入剖析了Python爬虫中自动重试机制的设计精髓，强调必须精准捕获ConnectionError、Timeout及5xx级HTTPError等真实网络异常，坚决避免用宽泛的Exception掩盖NameError、TypeError等逻辑错误；推荐采用3次重试配合带抖动的指数退避策略（如min(60, 2**attempt + random jitter)）以平衡稳定性与反封控，强制使用functools.wraps保留函数签名与文档提升可维护性，并特别警示非幂等请求（如POST）绝不能盲目装饰器重试，而需由业务层结合幂等性设计或状态预检来安全控制——真正可靠的重试，始于对失败本质的清醒判断。

重试装饰器该用哪个异常类型捕获

直接捕获 Exception 会吞掉你本该立刻发现的 bug，比如拼错变量名抛的 NameError，或者传了错误参数导致的 TypeError。真正该重试的只有网络层不稳定的错误：连接断开、超时、服务端临时 5xx。Requests 库里对应的是 requests.exceptions.ConnectionError、requests.exceptions.Timeout、requests.exceptions.HTTPError（需手动检查 status_code ≥ 500）。

实操建议：

• 不要写 except Exception:，宁可漏重试，也不掩盖逻辑错误
• 对 HTTPError 做二次判断：if e.response.status_code >= 500: 再重试
• 如果用了 httpx，对应异常是 httpx.ConnectError、httpx.TimeoutException

retry_times 和 delay 怎么设才不被封又不白等

重试不是越多越好，3 次是常见安全值；间隔也不能固定，否则大量请求会在同一毫秒撞上目标服务器——容易触发频率限制。必须用指数退避（exponential backoff），比如第一次等 1s，第二次等 2s，第三次等 4s，再加点随机抖动（jitter）。

实操建议：

• 默认从 retry_times=3 起手，观察日志里失败率再调
• 延迟用 min(60, (2 ** attempt) + random.uniform(0, 1))，上限卡死 60 秒防雪崩
• 别在重试里无脑加 time.sleep(1)，那只是“假装重试”，没解决并发冲突问题

装饰器怎么透传原始函数的签名和文档

用 functools.wraps 是底线操作。否则调试时看到的函数名是 wrapper，IDE 提示参数全丢，help(request_with_retry) 显示空文档——查问题时你会多花三倍时间。

实操建议：

• 每写一个装饰器，第一行就写 from functools import wraps，第二行就套 @wraps(func)
• 如果函数有 type hint（比如 def fetch(url: str) -> dict:），@wraps 会自动保留，不用额外处理
• 别自己手动复制 __name__ 和 __doc__，出错概率高还难维护

重试期间如何避免重复提交表单或修改状态

GET 请求天然幂等，重试安全；但 POST/PUT/DELETE 不是。如果第一次请求其实成功了，只是响应没收到，重试就会造成数据重复或误删。

实操建议：

• 对非 GET 方法，先确认接口是否支持幂等性（比如带 Idempotency-Key header）
• 没有幂等保障时，别在装饰器里自动重试 POST，改用业务层显式控制（例如先查再发）
• 日志里必须记录每次重试的请求 method + url + body hash，方便事后排查重复动作

重试最麻烦的从来不是写几行代码，而是得想清楚：这次失败，到底是真失败，还是“看起来失败”——而这个判断，没法交给装饰器自动做。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Python爬虫重试技巧：装饰器实现异常重试》文章吧，也可关注golang学习网公众号了解相关技术文章。