用 return_exceptions=True 可让 asyncio.gather 继续执行所有任务并返回包含异常对象的结果列表，再逐个判断类型处理；否则默认模式仅抛出首个异常并取消其余任务。
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 模式下，只抛出第一个异常，其余任务已被取消，它们的异常根本没机会冒出来——不是没捕获，是压根没发生。
常见误操作：写成这样以为能兜住所有错：
立即学习“Python免费学习笔记（深入）”；
try:
await asyncio.gather(a(), b(), c())
except Exception as e:
print("只看到这一个")
结果发现 b() 和 c() 的异常完全没打印。这不是异常被吞了，是它们根本没执行完就被 cancel 掉了。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 除非你显式调用
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或异步上下文管理器
真正的难点不在语法，而在区分“任务失败”和“任务被中断”。后者不是错误，是并发协调的副产品。
