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给你兜着
最容易被忽略的一点：TaskGroup 的 create_task 方法返回的 task 对象，**不能调用 cancel()**——它会被父 group 拦截并静默忽略。真要干预，只能等它自然结束或让整个 group 退出。
