发布于2026-06-22 阅读(0)
扫一扫,手机访问
先说一个非常常见的场景:当你同时扔出多个协程任务时,可能只想拿那些已经完成的结果,而不是傻等所有任务跑完。这时候,asyncio.wait 就是顺手的工具之一。但很多人刚上手时会发现,它返回的“已完成任务”集合里,其实混杂着成功与异常两种情况。这到底是怎么回事?怎么安全地把成功结果取出来?这些问题值得好好捋一捋。
当你传入一组协程任务时,如果有的已经结束(无论是正常返回还是抛了异常),有的还在运行中,asyncio.wait 会立即把完成和未完成的Task分两组返回给你。它只关心“结束”这个状态,不额外区分是成功还是失败——哪怕某个任务翻了车,它也会出现在 done 集合里。
所以,区分“哪些是成功的”这一步得自己来。方法是遍历 done 集合,用 task.exception() 检查有没有异常捕获,如果返回 None,说明任务正常完成,这时候再用 task.result() 取值才安全。下面是几个关键点:
done 里的 task 调 result(),万一任务失败了,会直接抛出未处理的异常。asyncio.wait 默认的行为是 return_when=asyncio.FIRST_COMPLETED,如果你想等待第一批完成的任务再返回,这个选项是对的;如果需要等待出现第一个异常就返回,用 FIRST_EXCEPTION;如果想等到全部结束,用 ALL_COMPLETED,但要小心它会阻塞直到所有任务完成。wait(..., timeout=1) 能做到“超时后只返回成功的任务”,其实不是的。超时后,未完成的任务仍然留在 pending 里,done 里只会包含那些确实已经结束的任务——失败的也包括在内。核心思路很简单:把“已完成”和“成功”两个条件分开判断。先过滤出 done 里没有异常的任务,再统一取结果:
done, pending = await asyncio.wait(tasks, timeout=2)
successful_results = []
for task in done:
if task.exception() is None:
successful_results.append(task.result())
这段代码的执行是稳健的,不会因为某个任务异常而中断,也不会试图从失败的任务中拿 result()。如果你需要记录失败原因用于后续重试或分析,可以额外收集 task.exception()。
再补充几个容易被忽略的细节:
task.cancelled() 来替代异常检查。取消和异常是两回事,当 cancelled() 返回 True 时,exception() 可能返回 CancelledError。None 是合法结果,千万不要靠 if task.result() 来判断是否成功——必须用 exception() 是否为 None 来判定。done 是一个 set,所以顺序是不保证的。如果需要按原始任务列表的顺序整理结果,记得提前给 task 加索引,或者在用 asyncio.create_task 包装时绑定上下文信息。timeout=0 并不是“不等待”,而是“最多等0秒”。它会立刻返回当前已经结束的任务,一个都没有的话,done 就是空集。而 return_when=FIRST_COMPLETED 则会至少等第一个任务结束才返回。
实际中这两者经常配合使用。比如你想“先看一眼有没有现成结果,没有的话才等着第一个完成”,那就先调 wait(..., timeout=0),如果 done 为空,再调 wait(..., return_when=FIRST_COMPLETED)。
timeout=0 在事件循环刚启动时返回空 done 是预期行为,不是bug。asyncio.to_thread——那么 done 会长期为空,这时需要配合重试或 fallback 逻辑。return_when 的其他选项(如 ALL_COMPLETED 或 FIRST_EXCEPTION)会改变阻塞行为,选错了会导致程序卡住或过早退出,使用时务必想清楚自己的实际需求。最常见的原因:任务已经被取消或异常结束了,但你跳过了 exception() 检查。举个例子:
task = asyncio.create_task(some_coro()) await asyncio.sleep(0.1) task.cancel() done, _ = await asyncio.wait([task]) # 此时 task in done 为 True,但 task.result() 会 raise CancelledError
另一个容易忽略的情况是:task 可能在 wait 返回前已经正常结束了,但你没来得及处理,后来又手动 cancel() 了它——这时候 exception() 返回的是 CancelledError,而不是原始的异常信息。
所以一个不得不说的习惯是:永远先确认 task.done(),再调 task.exception() 或 task.result(),这样可以避免 InvalidStateError。另外,如果你用 asyncio.ensure_future 创建任务,行为是一致的;但如果用 loop.create_task,要注意 loop 是否已经关闭。最后,在 finally 块里清理 pending 任务时,别忘了用 cancel() 加上 await asyncio.wait(...) 等它们真正结束,否则可能残留未处理的异常。
总结下来,实际使用中最关键的并不是“等多少个”或“超时多久”,而是每一次从 done 中取 task 后,必须做三个动作:先确认 done(),再检查 exception(),最后才取 result()。漏掉中间任何一环,都可能让看似稳妥的“部分成功”逻辑突然崩在异常上。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8