Python3.11TaskGroup使用详解

Python 3.11 引入的 `asyncio.TaskGroup` 并非只是 `gather` 的升级版，而是一种革命性的结构化并发机制——它用强制性的 `async with` 语法划出清晰的并发边界，彻底杜绝任务泄露、静默异常和生命周期失控等长期困扰异步开发的顽疾；通过 `tg.create_task()` 将子任务完全交由组统一调度，任一失败即熔断全部、异常精准传播、退出自动收尾，让你再也写不出“发了任务却忘了等”的危险代码——这不仅是新API，更是异步编程范式的根本性升级。

Python 3.11 的 asyncio.TaskGroup 不是“更好用的 gather”，它是用来防止任务泄露、确保异常不静默、让并发行为可预测的结构化边界。没它，asyncio.create_task() 像撒手没缰绳的马；有它，所有子任务才真正在一个“可控牢笼”里生灭。

必须用 async with，否则直接报错

这是硬性语法约束，不是风格建议。直接实例化 asyncio.TaskGroup() 或试图手动调用 __aenter__ 都会触发 RuntimeError: no active task group。

• async with asyncio.TaskGroup() as tg: 是唯一合法入口，离开该块时自动等待全部子任务结束（或被取消）
• 不能在 async with 外保留对 tg 的引用，更不能把它存进全局变量或类属性里传出去
• 如果想提前退出（比如某个条件满足后不再启新任务），直接 return 或 break 即可 —— async with 退出时仍会收尾

tg.create_task() 和 asyncio.create_task() 的本质区别

前者是后者的“受管版本”：它把任务生命周期完全交由 TaskGroup 控制，后者则完全由你手动管理，极易遗漏。

• tg.create_task() 返回的 Task 对象，其取消行为受组内统一调度 —— 任一失败，其余全 cancel
• asyncio.create_task() 创建的任务一旦脱离引用（比如循环中反复赋值覆盖变量），可能被静默丢弃，变成“僵尸任务”
• tg.create_task() 可以在 async with 块内任意位置动态调用，包括在另一个子任务的 await 后、if 分支里、甚至响应 API 数据后决定是否拉下一页

异常传播规则：只抛第一个，但会取消全部

这和 asyncio.gather(return_exceptions=False) 表面相似，但机制完全不同：前者是“等所有完成再汇总异常”，后者是“一个出事，立刻熔断”。

• 如果三个任务同时跑，第二个抛了 ValueError，TaskGroup 会立即向其余两个发送 cancel 信号，并在 async with 退出时只抛出那个 ValueError
• 不会打包成 ExceptionGroup，除非**多个任务在同一时刻抛出不同异常**（比如网络超时 + JSON 解析失败同时发生）
• 想捕获多异常？得用 except* 语法，而不是普通 except

别拿它当 gather 的平替：参数、返回值、适用场景都不同

TaskGroup 不接受协程对象列表，也不返回结果列表 —— 它只负责生命周期管理。你要自己存 Task 引用，再调用 .result() 拿结果。

• asyncio.gather(coro1(), coro2()) → 直接返回 [res1, res2]；tg.create_task(coro1()) → 得你自己存变量，最后 task1.result()
• gather 支持 return_exceptions=True 把异常也当结果返回；TaskGroup 不支持这个开关，异常就是异常
• 需要“部分失败继续执行”？TaskGroup 不干这事 —— 那是 asyncio.wait(..., return_when=asyncio.FIRST_COMPLETED) 或手动 create_task + done/pending 拆解的活

真正容易被忽略的点是：TaskGroup 的“结构化”不只体现在语法上，而在于它强制你把并发边界显式划出来。一旦你习惯在每个业务逻辑块里都用 async with asyncio.TaskGroup() 包一层，你就不会再写出“启动一堆任务然后忘了等”的代码 —— 因为语法根本不让你这么写。

理论要掌握，实操不能落！以上关于《Python3.11TaskGroup使用详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！