Python 3.11任务组优势及错误处理对比

Python 3.11 的 `asyncio.TaskGroup` 以结构化并发为核心，通过强制 `async with` 语法、自动取消失败任务、聚合异常为 `ExceptionGroup` 并支持精准的 `except*` 捕获，彻底解决了传统 `gather()` 易导致资源泄漏、状态不一致和异常处理繁琐等顽疾；它不是语法糖，而是一套严谨的生命周期契约——漏掉上下文管理、误用任务创建方式或沿用旧式异常捕获都会使安全机制失效，但一旦正确使用，就能在错误路径上获得更低开销、更清晰回溯和更强的资源保障，真正实现“失败即清理、异常可归因、并发有边界”的现代异步编程体验。

TaskGroup 会自动取消其余任务，gather 默认不会

当某个子任务抛出异常时，asyncio.TaskGroup 立即触发协作式取消：所有仍在运行的任务收到 CancelledError，并尽快退出。这是结构化并发的强制保障，避免“孤儿任务”继续占用连接、内存或 CPU。

asyncio.gather() 默认行为相反：只要一个任务失败，它立刻把异常向上抛，但其他任务照常运行——哪怕你没做任何处理，它们也会在后台悄悄跑完或卡死。这容易导致资源泄漏、超时叠加、状态不一致。

• 用 gather(..., return_exceptions=True) 可以把异常转成返回值，但你要自己遍历结果、逐个判断是否为 Exception 实例
• TaskGroup 不需要你手动检查；离开 async with 块时，所有异常（包括多个）会被打包进 ExceptionGroup 一次抛出
• 若想只捕获某类异常，直接用 except* ValueError:，不用写一堆 isinstance()

TaskGroup 必须用 async with，gather 没有语法约束

asyncio.TaskGroup 是上下文管理器，不是普通类。你不能写 tg = asyncio.TaskGroup()，也不能手动调用 __aenter__ 或 __aexit__——这些都不是公开 API，行为不可靠。

正确写法只有一种：async with asyncio.TaskGroup() as tg:。此时框架会确保：无论正常退出还是异常中断，所有已创建任务都会被等待、清理、异常聚合。

• 忘记 async with 直接 new 一个对象？Python 会报 RuntimeError: TaskGroup is not running
• 在 async with 块里用 tg.create_task() 启动任务，不是 asyncio.create_task()
• 任务中途可以动态增删，比如根据响应内容决定是否启动下一页请求，gather 完全不支持这种模式

ExceptionGroup 是 Python 3.11 的配套机制，不是可选附加

TaskGroup 抛出的异常类型是 ExceptionGroup，不是单个 ValueError 或 TimeoutError。如果你还用老式 except ValueError:，会完全捕获不到——它被包在 ExceptionGroup 里了。

必须用 except* 语法才能解包匹配：

try:
    async with asyncio.TaskGroup() as tg:
        tg.create_task(task_fail())
        tg.create_task(task_slow())
except* ValueError as eg:
    print("至少有一个 ValueError:", eg.exceptions)
except* TimeoutError:
    print("有超时任务")

• except* 是 Python 3.11 新增语法，3.10 及更早版本不支持
• ExceptionGroup 支持嵌套，比如子任务组再抛出 ExceptionGroup，外层仍能统一处理
• 如果没写任何 except*，异常会原样冒泡，但 traceback 会明确标出每个子异常来源（Python 3.11 的带注释 traceback 会高亮 ^ 和 ~）

性能开销其实更低，尤其在错误路径上

Python 3.11 引入了“零成本异常处理”（Zero-Cost Exception Handling），意味着 try/except 块本身不带来运行时开销——只有真正抛异常时才计算回溯信息。而 TaskGroup 正是基于这套机制设计的。

相比之下，gather(..., return_exceptions=True) 要求你对每个返回值做类型检查，实际增加了 CPU 分支判断和对象判等开销，尤其在大量任务成功、仅少数失败时，这种检查纯属冗余。

• TaskGroup 的异常传播是事件循环级的，不依赖用户代码遍历
• 它不缓存中间结果，也不构造额外 list，内存占用更可控
• 如果你的场景需要“部分失败继续执行”，那 TaskGroup 不适合——它天生是强一致性的，这不是缺陷，而是设计选择

真正的复杂点不在语法，而在思维切换：从“我来管任务生命周期”变成“交给结构化并发协议”。一旦漏掉 async with，或误用 create_task，整个异常隔离和资源清理就失效了。这不是 bug，是契约未履行。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~