asyncio.wait_for是最直接的超时控制方式，能在协程超时时抛出asyncio.TimeoutError，但不取消底层I/O；asyncio.timeout是Python 3.11+推荐的上下文管理器，语义清晰且自动管理状态；HTTP客户端内置timeout更底层高效，应优先配置；自定义逻辑需谨慎管理Task生命周期与资源清理。
asyncio.wait_for 是最直接的超时控制方式
它能在协程运行超过指定时间后主动抛出 asyncio.TimeoutError，适合对单个协程设限。注意它不会真正取消底层任务（比如已发出的 HTTP 请求），只是让调用方提前退出。
常见错误是误以为 wait_for 能强制中断正在执行的 I/O 操作——实际上它只中断等待结果的协程挂起状态，被包裹的协程可能仍在后台运行。
- 必须传入协程对象（
awaitable），不能传普通函数或已await过的结果 - 超时时间为浮点秒数，支持小数如
0.1；设为None表示永不超时 - 若被等待的协程本身已取消，
wait_for会直接传播CancelledError，而非抛出TimeoutError
try:
result = await asyncio.wait_for(fetch_data(), timeout=3.0)
except asyncio.TimeoutError:
print("fetch_data took too long")
asyncio.timeout 上下文管理器更符合直觉
Python 3.11+ 引入的 asyncio.timeout 是推荐的现代写法，语义清晰、嵌套友好，且自动处理进入/退出时的超时状态切换。
它本质是基于 wait_for 的封装，但避免了手动捕获异常和重复写 timeout= 参数的冗余。在多层异步调用中，比层层传递 timeout 参数更可靠。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 必须配合
async with使用，不能单独实例化 - 超时触发时抛出
TimeoutError（不是asyncio.TimeoutError），注意异常类型差异 - 如果在
async with块内发生其他异常，超时上下文会正常退出，不影响异常传播
async with asyncio.timeout(5.0):
data = await download_file(url)
自定义超时逻辑需小心协程生命周期
当需要“软超时”（比如允许当前请求完成但拒绝新请求）或组合多个超时条件时，不能只依赖 wait_for 或 timeout，得手动管理 asyncio.Task 和 asyncio.CancelledError。
关键点在于：显式创建 Task 后，超时触发时应调用 task.cancel()，并在被取消的协程中正确处理 CancelledError，否则可能留下僵尸任务或资源泄漏。
- 不要用
create_task后放任不管——务必保留 task 引用以便后续 cancel - 被取消的协程里，
try/except CancelledError应在最外层，或确保 finally 块能释放连接、关闭文件等 - 避免在取消后继续
await已取消的 task，会立即抛出CancelledError
HTTP 客户端库自身的 timeout 优先于 asyncio 层
像 aiohttp 或 httpx 都内置了连接、读取、总耗时等多级 timeout 控制。这些是在协议栈更低层生效的，比 asyncio.wait_for 更早终止 I/O，也更节省资源。
如果你用 wait_for 包裹一个已经设置了内部 timeout 的请求，实际效果是双重限制：内部 timeout 先断开 socket，外部 wait_for 再抛异常。多数情况下，只需配置客户端自己的 timeout 即可。
-
aiohttp.ClientTimeout支持total、connect、sock_read等细粒度参数 -
httpx.AsyncClient(timeout=...)接收Timeout实例，也可设为None关闭超时 - 混用时，客户端 timeout 触发后，
wait_for可能收不到异常（因协程已结束），导致超时逻辑失效
timeout= 就完事，真正难的是判断该在哪一层设限、如何清理残留状态、以及不同 timeout 机制之间的协作边界。 
