17370845950

asyncio.gather(return_exceptions=True)返回混合结果列表，元素为正常值或Exception实例，需用isinstance(item, Exception)逐项判断；成功结果与异常可分别用列表推导式提取，并注意异常序列化、日志及内存问题。

asyncio.gather(return_exceptions=True) 返回的是混合结果列表

调用 asyncio.gather(return_exceptions=True) 后，返回值是一个 list，其中每个元素要么是对应协程的正常返回值，要么是一个 Exception 实例（不是被抛出，而是作为值存在）。这意味着你不能直接对整个结果做逻辑判断或解包，必须逐项检查类型。

• 常见错误：把结果当纯成功值用，比如 result[0].some_method()，结果在第 0 项是 TimeoutError 时直接报 AttributeError
• 正确做法是统一用 isinstance(item, Exception) 判断，而不是靠 try/except 包裹访问
• 注意：BaseException 子类（如 SystemExit, KeyboardInterrupt）也可能出现，但通常 return_exceptions=True 只捕获协程内抛出的异常，不包括事件循环中断

如何安全提取成功结果并分类异常

最常用模式是用列表推导式分离成功值和异常，同时保留原始索引关系便于调试。不要用 filter 或 map 隐藏类型判断逻辑，可读性差且难调试。

• [r for r in results if not isinstance(r, Exception)] —— 只取成功结果
• [(i, r) for i, r in enumerate(results) if isinstance(r, Exception)] —— 带索引的异常列表，方便定位哪个任务失败
• 如果需要区分异常类型再处理，用 isinstance(r, TimeoutError) 或 type(r).__name__，避免用 str(r) 做模糊匹配
• 别忘了：空异常列表不等于“全部成功”，要确认 len(results) == len(expected_tasks)，防止任务数传错导致漏判

与 return_exceptions=False 的行为差异直接影响错误传播

设为 False（默认）时，只要任一协程抛异常，gather 立即中止并把第一个异常原样抛出，其余协程可能还在运行（取决于是否已取消）。而 True 下所有协程都会完成，异常被“吞”进结果里——这是两种完全不同的错误处理契约。

• 选 True 的典型场景：批量请求 API，允许部分失败，后续要聚合统计或重试
• 选 False 的典型场景：多个强依赖步骤（如先 auth 再 fetch），一个失败整条链无意义
• 性能影响：两者调度开销几乎一致，但 True 会多一次结果遍历判断，对几千个任务才需留意
• 兼容性：Python 3.7+ 行为一致，无需额外适配

常见陷阱：异常对象未被显式处理就进入日志或序列化

把整个 results 直接传给 logging.error(results) 或 json.dumps(results) 会失败——Exception 实例不可 JSON 序列化，logging 默认只打 repr，但可读性差。

• 写日志前先格式化异常：str(e) 或 traceback.format_exception(type(e), e, e.__traceback__)
• 序列化前过滤或转换：[r if not isinstance(r, Exception) else {'error': type(r).__name__, 'message': str(r)} for r in results]
• 别忽略异常的 __traceback__ 属性——它指向协程内出错位置，但仅在异常被 raise 过才有效；return_exceptions=True 下该属性仍保留，可用 traceback.print_exception() 打印完整上下文
• 最容易被忽略的一点：异常对象本身可能持有大内存引用（比如它捕获了某个大型 response 对象），不及时清理可能引发意外内存滞留