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

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 强制你「必须等待所有任务结束」，避免遗漏
异常传播更干净：默认不吞异常，且能区分是哪个子任务出的错（通过 except* 或检查 BaseExceptionGroup）
不支持嵌套取消（比如只取消其中某个子任务），这是设计取舍：它面向的是“原子性任务组”，不是灵活调度器

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

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

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

限流：在 tg.create_task(...) 前 await 一个 semaphore.acquire()，并在任务结束时 semaphore.release()（推荐封装成 async context manager）
整组超时：把 async with asyncio.TaskGroup() as tg: 放进 asyncio.wait_for(tg_context, timeout=3) ——注意这不是直接 await tg，而是 await 一个包装了 tg 的协程
别对单个 tg.create_task(...) 套 wait_for：会破坏 TaskGroup 的统一取消机制，导致其他任务继续运行

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

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

关键点：不要用普通 except Exception:，要用 except* ValueError:（匹配子异常类型）或遍历 exc.exceptions。

示例：若想单独处理 HTTP 错误，可写 except* aiohttp.ClientError as eg:
想看每个失败任务的原始协程名？从 eg.exceptions[0].__cause__ 往上溯，或在创建任务时传入 name="fetch_user_123" 参数（3.12+ 支持）
如果用了 return_exceptions=True（不推荐），异常会变成结果列表里的元素，但此时 TaskGroup 不再自动取消其余任务——等于退化成 gather，失去核心价值

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

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

要随时取消某个任务？改用 asyncio.create_task + 显式 task.cancel() + asyncio.shield 保护关键清理逻辑
任务之间要通信？加 asyncio.Queue 或 asyncio.Event，但别塞进同一个 TaskGroup——那会让生命周期耦合
过紧
后台服务类任务（如心跳、日志轮转）？用独立 asyncio.create_task 并确保有异常兜底（try/except + logger.exception），别指望 TaskGroup 给你兜着