async with asyncio.timeout()更适合流式场景，因其上下文感知、不中断迭代节奏、错误类型统一为timeouterror；但嵌套使用会导致外层逻辑静默跳过，且会覆盖langgraph等框架的上下文配置。
Python 3.11 的 async with timeout() 让异步超时控制从“手动兜底”变成“声明式收口”，但直接套用会踩坑——它不兼容嵌套超时取消逻辑，且和 asyncio.wait_for() 行为不一致。
async with timeout() 为什么比 wait_for() 更适合流式场景
旧写法用 asyncio.wait_for() 容易在流式响应中途被粗暴中断，丢失已收到的部分数据；而 async with timeout(5) 是上下文感知的：它只在进入块时启动计时器，退出时自动清理，不干扰内部 aiter 或 anext 的迭代节奏。
- 适用于 HTTP 流式响应、LangGraph 节点间接力、SSE 长连接等需要“保底不卡死”的场景
- 支持动态调整：同一协程中可嵌套多个
async with timeout(n)，内层超时优先触发 - 错误类型统一为
asyncio.TimeoutError，无需额外捕获CancelledError
timeout() 嵌套时的取消传播陷阱
看似能嵌套，实则内层 async with timeout(1) 触发后，外层 async with timeout(10) 不会自动恢复——它的任务已被取消，后续代码不会执行。这不是 bug，而是 asyncio 取消语义的必然结果。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 避免写成：外层设长超时保底 + 内层设短超时试探，这会导致外层逻辑被静默跳过
- 正确做法是用单层
timeout()+ 显式重试逻辑，例如在 except 块里调用await asyncio.sleep(0.1)后重进循环 - 若需分级响应，改用
asyncio.wait()手动管理多个Task，而非依赖嵌套上下文
与 LangGraph 异步节点配合时的 config 传递冲突
Python 3.11+ 中 llm.ainvoke() 自动继承上下文变量，但 async with timeout() 创建的新上下文会覆盖原有 RunnableConfig，导致 trace_id、metadata 等丢失。
- 必须在
async with timeout()块外提前提取并显式传入关键配置，例如：config = get_config() - 不要在 timeout 块内调用
ensure_context()或类似辅助函数——它们可能触发新的 contextvars.set()，覆盖原始值 - 验证方式：在节点函数开头打印
config.get("run_id")，若为None就说明上下文被截断了
最易被忽略的是 timeout 的“不可逆性”：一旦触发，对应 Task 的状态就不可恢复，哪怕你 catch 住异常并继续 await 其他协程，原 Task 也不会复活。这和同步代码里的 try-except 有本质区别。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
