tenacity 不加 stop_after_delay 和 retry_if_exception_type 会导致超时请求拖长、压垮下游、刷屏日志；requests 默认重试仅覆盖连接层异常和少数状态码，无法处理业务级失败。
直接说结论：不加 stop_after_delay 和 retry_if_exception_type 的 tenacity 重试，大概率会把超时请求越拖越久、把下游打崩、把日志刷屏——这不是容错，是自我攻击。
为什么 requests 自带重试根本挡不住业务失败
requests.adapters.HTTPAdapter 的 Retry 类只认连接层异常（比如 ConnectionError、Timeout）和少数 HTTP 状态码（如 429、503），对以下情况完全无感：
- 返回
200但 body 里是{"code": "RATE_LIMITED"} - 第三方 API 明确返回
500表示内部逻辑错误，而非临时不可用 - 你设置了
timeout=(3, 10)，但重试 3 次后总耗时可能逼近 40 秒
更危险的是：Retry 不支持 jitter，所有客户端在第 2 秒同时重试，极易触发雪崩。
必须显式控制总耗时：stop_after_delay 是底线
很多人以为 stop_after_attempt(3) 就够了，但没算网络层叠加的 timeout。真实耗时 = 单次 timeout × 重试次数 + 等待间隔之和。比如 timeout=(3, 10) + wait_exponential()，3 次重试可能卡住 39 秒以上。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 用
stop_after_delay(8)强制整个重试过程最多花 8 秒，超时立刻放弃 - 组合使用：
stop=(stop_after_attempt(3) | stop_after_delay(8))，任一条件满足即停 - 注意：
stop_after_delay计的是从第一次调用开始的 wall-clock 时间，不是纯等待时间
只对真正可重试的异常重试：别 catch 一切
把 Exception 或 BaseException 当重试条件，等于给逻辑错误（比如 KeyError、TypeError）反复喂毒药。
- 明确指定：
retry=retry_if_exception_type((requests.Timeout, requests.ConnectionError)) - 若需响应体判断，用
retry_if_result+ lambda：retry_if_result(lambda r: r.get("code") == "TEMP_UNAVAILABLE") - 避免重试 4xx 错误（如
401 Unauthorized、404 Not Found），它们通常不随重试而恢复
指数退避必须加 jitter：否则就是定时炸弹
wait_exponential() 默认不带随机扰动，所有请求按固定节奏重试，在高并发下会形成脉冲式流量高峰。
- 改用
wait_exponential_jitter(initial=1, max=60)，每次等待在指数基础上加 ±0.5 秒随机抖动 - 或手动组合：
wait_fixed(2) + wait_random(0, 1)，固定 2 秒再加最多 1 秒随机延迟 - 不要用
multiplier=0.1这类小值——它会让首次等待变成 0.1 秒，失去退避意义
真正难的不是写对那几行 @retry，而是想清楚：这次失败到底是不是临时的？重试会不会让问题更糟？超时边界有没有被业务方真正接受？这些判断没法交给库自动做。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
