<p>TaskGroup 在任务失败时自动取消其余任务，而 gather 默认不取消；TaskGroup 必须用 async with 使用，抛出 ExceptionGroup 异常，需用 except* 捕获，且只能用 tg.create_task() 创建受管任务。</p>
TaskGroup 任务失败时自动取消其他任务，gather 默认不取消
当一个子任务抛出异常，asyncio.TaskGroup会立刻向所有仍在运行的子任务发送取消信号（CancelledError），并等待它们响应后才退出上下文；而asyncio.gather()默认行为是“只抛第一个异常，其余任务照常跑”，哪怕你没写任何清理逻辑，它们也可能在后台持续占用连接、文件句柄或内存。
- 用
gather(return_exceptions=True)可以把异常塞进返回值列表，但你要自己遍历判断每个元素是不是Exception实例——漏一个就可能埋下泄漏隐患 -
TaskGroup的取消是协作式、可中断的：子任务若在async with或try/finally块中，能安全执行清理逻辑后再退出 - 如果你手动调用
task.cancel()再await task模拟 gather 的“取消”，代码量大、易错，且无法保证嵌套子任务也被递归取消
必须用 async with，否则 RuntimeError: TaskGroup is not running
asyncio.TaskGroup 不是普通类，不能直接实例化：tg = asyncio.TaskGroup() 或 tg = asyncio.TaskGroup().__enter__() 都会触发 RuntimeError: TaskGroup is not running。它只接受一种合法入口：
- 必须写成
async with asyncio.TaskGroup() as tg:，离开该块时框架自动调用__aexit__，完成等待、取消、异常聚合全流程 - 不能把
tg存到全局变量、类属性或传给另一个协程——一旦离开async with块，tg就失效，再调用tg.create_task()会报RuntimeError: TaskGroup is closed - 想提前终止新任务创建？直接
return或break即可，收尾逻辑仍由上下文管理器保证
异常类型是 ExceptionGroup，不是单个 ValueError
TaskGroup 抛出的异常永远是 ExceptionGroup（或其子类 BaseExceptionGroup），哪怕只有一个任务失败。这意味着你不能再用老式 except ValueError: 捕获——它被包在 ExceptionGroup 里了，根本匹配不到。
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 正确写法是
except* ValueError:，这是 Python 3.11 新增语法，专为匹配ExceptionGroup设计 - 如果多个任务同时失败（比如网络超时 + JSON 解析错误），
ExceptionGroup.exceptions会包含多个不同类型的异常，except*可按类型分别处理 - 别试图在
async with块内用try/except包住单个tg.create_task()来“吞掉异常”——这会破坏组内统一取消机制，让其他任务继续运行
不能混用 create_task 和 tg.create_task
在 async with asyncio.TaskGroup() as tg: 块内，必须用 tg.create_task() 启动子任务；若误用 asyncio.create_task()，该任务将脱离 TaskGroup 管理，既不会被自动取消，也不会参与异常聚合，变成“孤儿任务”。
立即学习“Python免费学习笔记（深入）”；
-
tg.create_task()返回的Task对象，其生命周期完全由组控制：组退出时自动await它，失败时统一取消它 -
asyncio.create_task()创建的任务，引用丢失后可能被静默回收，尤其在循环中反复赋值覆盖变量时，极易产生僵尸任务 - 动态场景（如根据 API 响应决定是否拉下一页）只能靠
tg.create_task()实现——gather要求任务列表预先固定，不支持运行时增删
TaskGroup 的自动取消不是“更狠的 gather”，而是结构化边界的刚性约束。最容易被忽略的是：它要求你彻底放弃“手动管理任务生命周期”的惯性思维，所有子任务必须出生、存活、死亡都在同一个 async with 块内完成。
