asyncio.gather异常处理方法

`asyncio.gather` 默认遇到首个异常就会中断所有任务并抛出该错误，导致其余协程的失败被掩盖；而通过启用 `return_exceptions=True` 参数，它能完整执行全部协程，并将成功结果与异常对象（包括业务异常和因取消产生的 `CancelledError`）一并按输入顺序返回为列表，从而支持统一、可控的批量错误分拣与处理——这不仅是绕过默认中断行为的唯一标准解法，更契合“确定输入、关注成败、保持顺序”的典型并发场景，但需注意区分真正的业务错误与并发协调引发的中断信号。

asyncio.gather 抛出第一个异常就中断，怎么让它继续跑完所有任务？

默认情况下，asyncio.gather 遇到任一协程抛出异常，会立即取消其余未完成的任务，并把第一个异常直接 raise 出来——这和你“想等全部结束再统一处理错误”的直觉相悖。

根本原因是 asyncio.gather 的 return_exceptions=False（默认值）设计：它不把异常当返回值，而是当流程中断信号。

• 加参数 return_exceptions=True，所有结果（含 Exception 实例）都会原样放进返回列表
• 之后用 isinstance(..., Exception) 逐个判断，而不是靠 try/except 包裹整个 gather 调用
• 注意：即使开了这个开关，被取消的任务仍可能触发 CancelledError，但那是取消副作用，不是你原始协程抛的错

results = await asyncio.gather(
    fetch_user(1),
    fetch_user(999),  # 404 → HTTPError
    fetch_user(2),
    return_exceptions=True
)
for r in results:
    if isinstance(r, Exception):
        print(f"失败: {r}")
    else:
        print(f"成功: {r}")

为什么 try/except 包住 gather 还是捕获不到后续异常？

因为 asyncio.gather 在 return_exceptions=False 模式下，只抛出第一个异常，其余任务已被取消，它们的异常根本没机会冒出来——不是没捕获，是压根没发生。

常见误操作：写成这样以为能兜住所有错：

try:
    await asyncio.gather(a(), b(), c())
except Exception as e:
    print("只看到这一个")

结果发现 b() 和 c() 的异常完全没打印。这不是异常被吞了，是它们根本没执行完就被 cancel 掉了。

• 除非你显式调用 asyncio.create_task 并手动 await 每个，否则别指望 gather 默认模式返回多个异常
• return_exceptions=True 是唯一标准解法；试图用 asyncio.wait + return_when=ALL_COMPLETED 也能做到，但代码更啰嗦、错误提取更麻烦

asyncio.gather 和 asyncio.wait 在错误收集上有什么实际区别？

asyncio.wait 确实能等全部完成（配 return_when=asyncio.ALL_COMPLETED），但它返回的是 (done, pending) 集合，每个 Task 的结果得手动 task.result() 取，而且一旦取到已失败的 task，就会立刻 raise 异常——你还是得包 try/except 在每一项上。

而 gather(..., return_exceptions=True) 直接给你一个对齐输入顺序的扁平列表，异常和值混排，处理起来更贴近“批处理”直觉。

• gather 更适合「输入确定、顺序重要、想简单分拣成败」的场景
• wait 更适合「需要动态增删任务、或要响应部分完成就行动」的场景，但错误处理成本高一截
• 性能上无实质差异，都是事件循环调度，别为这个选型

容易忽略的 CancelledError 陷阱

开启 return_exceptions=True 后，你可能会在结果里看到 asyncio.CancelledError，但它往往不是你业务逻辑抛的，而是 gather 内部取消其他任务时注入的。

比如 a() 先失败，b() 正在运行中就被 cancel，此时 b() 的返回值就是 CancelledError 实例——但这不代表 b() 自己出错了，只是被强行打断了。

• 如果业务上要求“必须执行完”，那 gather 本身就不适用，得换 create_task + 显式 await
• 如果只是想统计哪些成功/失败，建议过滤掉 CancelledError，只保留你关心的业务异常类型
• 别在 except CancelledError: 里做资源清理——那是 asyncio 底层的事，你的协程该用 finally 或异步上下文管理器

真正的难点不在语法，而在区分“任务失败”和“任务被中断”。后者不是错误，是并发协调的副产品。

今天关于《asyncio.gather异常处理方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！