合理重试需满足三个条件：只对可恢复错误重试，限制总次数和等待时间，采用指数退避；需结合状态码、响应内容、登录态、熔断机制与日志监控综合实现。
爬虫运行中遇到网络波动、目标服务器拒绝、超时或反爬响应（如403、503、429）很常见，光靠try...except捕获异常远远不够——关键是要有策略地重试，并避免无意义的反复请求、IP被封或资源浪费。
重试不是“多试几次”，而是有节制、有退避、有判断
盲目循环重试会加重服务压力，也可能触发风控。合理重试需满足三个条件：只对可恢复错误重试（如超时、连接中断），对明确失败（如404、401）直接放弃；限制总次数和单次等待时间；每次间隔逐步拉长（指数退避）。
- 用
requests.adapters.Retry配置底层重试策略，支持状态码、异常类型、最大重试数、退避因子 - 示例：对连接错误、读取超时、5xx服务端错误重试3次，首次延迟1秒，后续按2的幂次递增（1s→2s→4s）
- 注意绕过默认不重试的3xx重定向（除非你明确需要）和4xx客户端错误（多数不可恢复）
结合业务逻辑做“语义化重试判断”
HTTP状态码只是表层，真正要关注的是响应内容是否符合预期。比如返回200但页面是反爬验证页、空JSON、或含“请稍后再试”文案，此时应视同失败并重试。
- 自定义检查函数：解析响应后判断
response.text是否含特定关键词，或response.json()结构是否完整 - 把这类检查嵌入重试条件，例如用
tenacity库的retry_if_result或retry_if_exception_type组合使用 - 避免重试已登录态失效（如cookie过期）导致的重复401，可在重试前先刷新session或token
避免重试放大风险：加锁、计数与熔断
高频重试可能让单个IP在短时间内发出大量请求，极易被封。需从工程层面控制节奏和范围。
立即学习“Python免费学习笔记（深入）”；
- 为每个请求URL或目标域名维护独立重试计数器，防止某接口异常拖垮整个爬虫任务
- 使用分布式锁（如Redis锁）协调多进程/多机爬虫对同一资源的重试节奏
- 引入熔断机制：当某接口连续N次失败，暂停对该接口所有请求一段时间（如5分钟），到期后试探性恢复
日志与可观测性：让重试“看得见、可追溯”
没有日志的重试等于黑盒操作。每次重试都应记录原始请求、失败原因、重试次数、当前退避时长、最终结果。
- 用
logging打结构化日志，字段包含url、method、status_code、reason、retry_count、backoff_seconds - 对重试超过2次的请求单独告警（如写入告警队列或发邮件），便于人工介入
- 统计维度可扩展：按域名、状态码分布、平均重试耗时，用于优化策略
不复杂但容易忽略：一次成功的重试，背后是错误分类、退避设计、状态感知和资源约束的综合平衡。写死time.sleep(1); continue不是容错，是埋雷。
