TaskGroup通过强制结构化并发避免僵尸任务和资源泄漏：必须用async with启动，自动统一取消/等待子任务；任一异常即传播CancelledError并精准抛出ExceptionGroup，需用except*捕获以确保清理。
TaskGroup 本身不提升单任务执行速度，但它能显著减少因异常、取消或资源泄漏导致的隐性性能损耗——比如后台僵尸任务持续占连接、文件句柄或重试循环。
TaskGroup 怎么避免“后台任务偷偷吃资源”
传统 asyncio.create_task() 启动的任务一旦脱离引用（比如在循环里反复覆盖变量名），就可能变成无人 await、无人 cancel 的“僵尸任务”。它们还在跑 HTTP 请求、持有数据库连接、轮询文件锁，但你完全感知不到。
TaskGroup 强制所有子任务绑定到 async with 生命周期：块退出时，无论正常结束还是异常中断，框架自动等待或取消全部已启动任务。没有漏网之鱼。
- 不用手动写
try/finally+task.cancel()+await task组合 - 不会出现“价格服务报错后，库存请求还在发第5次重试”的情况
- 连接池、临时文件、锁等资源能随任务一起释放，而不是靠 GC 碰运气
取消传播为什么直接影响性能表现
用 asyncio.gather() 时，一个子任务抛 ValueError，其余任务照常运行。它们可能继续发网络请求、解码大 JSON、写磁盘——这些操作都在白费 CPU 和 I/O。
立即学习“Python免费学习笔记（深入）”；
TaskGroup 在首个异常发生时，立刻向其余任务发送 CancelledError。只要子任务在 async with 或 try/finally 中做了清理，就能快速退出，不拖慢整体响应。
- 协作式取消是可中断的：任务可在 I/O 暂停点响应取消，不必硬等超时
- 避免了 gather +
return_exceptions=True后还要遍历结果、手动判断哪些是异常的额外开销 - 尤其在高并发 API 聚合场景（如电商首页加载 8 个微服务），熔断越快，尾延迟越低
ExceptionGroup 不是语法糖，是性能兜底机制
老式 except ValueError: 捕获不到 TaskGroup 抛出的异常，因为实际抛的是 ExceptionGroup。如果错误处理写错，异常被吞掉或误判，任务组可能提前退出而清理逻辑没执行——连接没关、缓存没删、状态没回滚，后续请求就会卡在资源争用上。
必须用 except* ValueError: 这种新语法，才能精准捕获并做针对性处理。
- 多个任务同时失败（比如 DNS 解析失败 + TLS 握手超时），
ExceptionGroup.exceptions包含全部原始异常，不用自己拼接上下文 - 避免因异常处理不全导致的“看似成功、实则部分数据脏写”问题
- 调试时直接看到哪几个子任务挂了，而不是只看到第一个抛错的堆栈
真正影响性能的往往不是协程跑得多快，而是任务生命周期是否可控、异常是否透明、取消是否及时——这些恰恰是 TaskGroup 用语法强制解决的点。写错 except* 或漏掉 async with，性能优势立刻归零。
