是的，asyncio.TaskGroup在任一子任务抛出未处理异常时会立即取消其余运行中任务并重新抛出该异常；其取消基于CancelledError，需协程主动让出控制权才能响应，且不提供失败任务元信息。
asyncio.TaskGroup 抛异常时是否自动取消其余任务
是的，asyncio.TaskGroup 在任一子任务抛出未处理异常时，会立即取消所有仍在运行的其他任务，并将该异常重新抛出到 with 语句块外。这是它的核心语义，不是可选行为，也不需要额外配置。
为什么 cancel() 不是“尽力而为”，而是强制同步中断
TaskGroup 的取消机制基于 asyncio.CancelledError，它会在当前任务的下一个 await 点被抛出（类似协程的协作式中断）。这意味着：
- 如果某个任务正阻塞在 CPU 密集型计算中（比如
time.sleep()或纯 Python 循环），它不会被及时取消——必须主动检查asyncio.current_task().cancelled()或插入await asyncio.sleep(0)让出控制权 - IO 类 awaitable（如
asyncio.sleep()、aiohttp.ClientSession.get()）通常能响应取消；但某些底层库（如未适配 asyncio 的数据库驱动）可能忽略 CancelledError - 任务退出前仍会执行
finally块或异步上下文管理器的__aexit__，可用于清理资源
如何捕获并区分哪个任务先失败
TaskGroup 不提供“谁先挂了”的元信息，异常就是第一个非 CancelledError 的那个。若需定位源头，常见做法是：
- 每个任务用独立的
try/except包裹，并把原始异常包装成带上下文的新异常，例如raise RuntimeError("task-a failed") from exc - 使用
asyncio.create_task(..., name="task-a")设置名称，再通过task.get_name()在异常处理器中记录（注意：仅限 Python 3.8+，且需在 task 启动后读取） - 避免在多个任务里抛相同类型异常（如都抛
ValueError），否则无法靠类型区分
和 asyncio.gather(return_exceptions=True) 的关键区别
asyncio.gather(..., retu 会吞掉所有异常，把它们当作普通返回值；而 
TaskGroup 是“一损俱损”。实际选择取决于语义需求：
- 要“全部完成，无论成败” → 用
gather(return_exceptions=True) - 要“原子性执行：全成或全败” → 用
TaskGroup - 想部分失败后继续执行其余任务？TaskGroup 不支持——得退回到手动管理
create_task+ 显式cancel()+ 异常聚合
最易被忽略的一点：TaskGroup 的取消传播是同步的，但任务真正退出可能有延迟；如果你在 with 块结束后立刻检查资源状态，可能看到部分任务还在 pending 或刚进入 cancelled，而非彻底结束。
