贝利信息

asyncio.TaskGroup 如何优雅管理一组相关任务的创建与取消

日期:2026-01-24 00:00 / 作者:冷漠man
asyncio.TaskGroup 更适合任务协同,因其内置“同进同出”生命周期:任一子任务异常则自动取消其余任务,且强制等待全部结束;而 create_task + gather 易遗漏取消逻辑,导致任务泄露。

asyncio.TaskGroup 为什么比 create_task + gather 更适合任务协同

因为 TaskGroup 内置了“同进同出”的生命周期约束:任一子任务异常,其余未完成任务自动取消;所有任务结束后自动退出上下文。而手动用 asyncio.create_task 配合 asyncio.gather(return_exceptions=True) 容易漏掉取消逻辑,尤其在异常分支里忘记调用 task.cancel(),导致后台任务泄露。

常见错误现象:RuntimeWarning: coroutine 'xxx' was never awaited 或程序退出后仍有协程在后台运行——这往往是因为用了 create_task 却没等它、也没显式取消。

如何在任务启动前就控制并发数或加超时

TaskGroup 本身不提供并发限制或超时参数,得靠外层控制。最常用的是配合 asyncio.Semaphore 或用 asyncio.wait_for 包裹整个 with TaskGroup() as tg: 块。

使用场景:爬取 100 个 URL,但最多并发 5 个;或整组任务必须在 3 秒内完成,否则全部取消。

子任务抛异常时,怎么拿到具体是哪个任务失败了

默认情况下,TaskGroup 把所有子任务异常聚合成一个 ExceptionGroup(Python 3.11+)或 BaseExceptionGroup(3.11 之前需 from exceptiongroup import ExceptionGroup)。不能靠打印 traceback 直接定位,得主动解包。

关键点:不要用普通 except Exception:,要用 except* ValueError:(匹配子异常类型)或遍历 exc.exceptions

什么时候不该用 TaskGroup,该换别的方案

当你需要「部分取消」「动态增删任务」「任务间传递信号」或「长时间后台守护任务」时,TaskGroup 就不合适了。它的边界非常清晰:一组有共同起点和终点的协作任务。

最容易被忽略的一点:TaskGroupcreate_task 方法返回的 task 对象,**不能调用 cancel()**——它会被父 group 拦截并静默忽略。真要干预,只能等它自然结束或让整个 group 退出。