TaskGroup防止类异步任务泄漏的根本原因是强制统一生命周期和错误命运：必须用async with启动，退出时自动await所有子任务，取消时广播信号并等待其执行async with/finally清理，异常聚合为ExceptionGroup抛出。
TaskGroup 对类异步任务有用，根本原因不是它“支持更多并发”，而是它强制给每个子任务绑上统一的生命周期和错误命运——只要你在 async with asyncio.TaskGroup() 块里用 tg.create_task() 启动任务，它们就不再是散兵游勇，而是一个进退同步、生死与共的作战单元。
TaskGroup 怎么防止“类异步任务”变成僵尸或泄漏？
类异步任务（比如封装了 httpx.AsyncClient、数据库连接池、文件句柄的协程）往往自带资源持有逻辑。若用 asyncio.create_task() 手动管理，极易出问题：
- 忘记在
except或finally里await任务 → 任务对象被丢弃，但底层 TCP 连接/锁/临时文件还挂着 - 多个任务共享一个
AsyncClient实例，某个任务崩溃后 client 被 close，其余任务直接抛RuntimeError: <client> is closed</client> - 循环中反复
create_task()却只保留最后一个变量 → 前面的任务引用丢失，无法取消也无法等待
TaskGroup 用语法硬约束解决这些：
- 必须走
async with，退出时自动await所有未完成任务（哪怕你没显式保存变量） - 所有
tg.create_task()创建的任务，其取消信号由组统一广播；任务内部若用了async with httpx.AsyncClient()，就能自然触发<strong>aexit</strong>清理 - 不允许把
tg引用传到块外，杜绝生命周期错位
TaskGroup 的异常传播机制对类任务意味着什么？
类任务失败时，往往不只是“结果错了”，而是“状态已污染”。比如：
立即学习“Python免费学习笔记（深入）”；
- 一个写入数据库的任务中途失败，事务没 commit 也没 rollback
- 一个上传文件的任务中断，临时分片残留、ETag 未校验
- 一个长轮询协程被 cancel，但没检查
task.cancelled()就继续 await 下一帧
TaskGroup 的处理是：第一个异常出现 → 立即向所有存活子任务发 cancel → 等它们各自走完清理逻辑（如 async with 块、try/finally）→ 最后聚合抛 ExceptionGroup
这意味着：
- 你不能再依赖“哪个任务先 finish 就先拿 result”，必须显式调用每个
task.result() - 若某个任务没响应 cancel（比如死循环里没检查
asyncio.current_task().cancelled()），async with会卡住，直到它自己退出或超时 -
except*是唯一能捕获ExceptionGroup的语法，普通except Exception会漏掉所有异常
为什么不能用 gather 替代 TaskGroup 处理类任务？
asyncio.gather() 只负责“等结果”，不插手生命周期：
- 它遇到第一个异常就立刻返回，其余任务继续后台跑 → 类任务可能持续占用连接、写脏数据、阻塞线程池
- 返回值是顺序固定的列表，但类任务的执行顺序本就不该被假设（比如依赖初始化顺序、锁竞争）
- 没有统一取消入口，你得自己遍历
task.cancel()，再await asyncio.wait(...)，代码量翻倍且易漏
而 TaskGroup 把“启动—等待—取消—清理”全收束在一个语法块里，类任务只要写对了自身清理逻辑（比如用 async with 包裹资源），就天然适配。
真正容易被忽略的一点：TaskGroup 的价值不在“它让代码跑得更快”，而在“它让代码失败时行为可预期”。类任务一旦涉及 I/O、状态、资源，静默失败比慢几十毫秒可怕得多——而这种静默，正是旧模式下最常踩的坑。
