asyncio.wait_for需手动封装重试逻辑，必须用循环控制并重置计时器；熔断状态须跨协程共享，推荐单例类加锁管理；重试与熔断应区分异常类型，仅故障型异常计入熔断统计。
asyncio.wait_for 无法直接实现重试，得自己包一层
Python 标准库的 asyncio.wait_for 只负责超时抛异常，不重试也不记录失败次数。想加重试逻辑，必须用 async for 或 while 循环手动控制，且每次重试前要重置计时器。
常见错误是把 wait_for 套在循环外，结果第一次超时就退出，根本没机会重试；或者忘了 await asyncio.sleep() 做退避，导致瞬间打爆下游服务。
- 重试前建议加指数退避：
await asyncio.sleep(min(2 ** attempt, 60)) - 超时时间建议随重试递增（比如从 1s → 2s → 4s），避免重复卡死在同一耗时点
- 捕获
asyncio.TimeoutError，别用通用Exception，否则会吞掉真实业务异常
熔断状态必须跨协程共享，不能用局部变量
协程之间不共享栈帧，每个 async def 函数里的变量都是独立的。如果把熔断开关（如 is_open）定义在函数内部，那每次调用都是新状态，完全起不到熔断作用。
正确做法是用类属性、模块级变量，或更稳妥的——用 asyncio.Lock + 字典做线程/协程安全的状态管理。尤其要注意并发请求同时触发熔断打开和半开探测时的竞争条件。
- 推荐用单例类封装熔断器，状态存在类变量里，比如
CircuitBreaker._state - 状态变更（
closed→open→half_open）必须加锁，否则两个并发请求可能同时把open改成half_open - 半开状态下只允许一个探测请求通过，其余请求应直接抛
CircuitBreakerOpenError，而不是排队等待
重试 + 熔断组合时，失败计数要区分“超时”和“业务错误”
不是所有失败都该计入熔断统计。比如网络超时说明下游不可达，该进熔断；但 ValueError 或 400 Bad Request 是上游参数问题，重试也没用，不该拉低成功率。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
标准做法是在重试循环里对异常类型分类：仅将 asyncio.TimeoutError、ConnectionError、ClientConnectorError（aiohttp）等归为“故障型异常”，其他跳过计数。
- 熔断器的失败阈值（如连续 5 次失败）只针对故障型异常累加
- 重试次数限制（如最多 3 次）则对所有异常生效，防止无限循环
- 用
isinstance(e, (asyncio.TimeoutError, aiohttp.ClientConnectorError))判断比字符串匹配更可靠
aiohttp + tenacity 组合容易踩内存泄漏坑
有人直接用 tenacity 的 @retry 装饰异步函数，但默认配置下它会在每次重试时新建 session，而旧 session 不 close 就会导致连接未释放，最终触发 Unclosed connector 警告甚至内存增长。
根本原因是 tenacity 同步重试器不感知 async context，无法自动 await cleanup。解决方案只有两个：不用 tenacity，或严格控制 session 生命周期。
- 推荐手写重试逻辑，把
aiohttp.ClientSession作为参数传入，由调用方负责创建和关闭 - 若坚持用 tenacity，必须配合
before_sleep回调手动await session.close()，且确保 session 是可重入的（比如用async with包裹每次请求） - 测试时用
pytest-asyncio+async with aiohttp.ClientSession() as session:包住整个测试函数，避免 session 泄漏干扰判断
实际最难的部分不是写逻辑，而是确定哪些异常该重试、哪些该熔断、哪些该直接失败——这得看下游服务的 SLA 和错误响应语义，没有银弹。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
