exceptiongroup 不提升性能，而是解决异常处理的可维护性与可靠性问题；需配合 asyncio.taskgroup 和 except* 语法使用，且协程必须可取消才能发挥其结构化并发优势。
ExceptionGroup 本身不提升性能，它解决的是异常处理的可维护性与可靠性问题。真正影响性能的是你是否用对了结构——比如用 asyncio.TaskGroup 替代 asyncio.gather，避免资源泄漏和重复轮询。
为什么 except* 比 try/except Exception 更适合并发场景
普通 except Exception 无法捕获 ExceptionGroup，因为后者继承自 BaseException，而非 Exception。强行用旧写法会导致异常被忽略或意外中断。
-
except*是 Python 3.11 新语法，专为匹配ExceptionGroup设计，能精准分流子异常类型 - 若同时发生
httpx.HTTPStatusError和asyncio.TimeoutError，两个except*块都会触发，无需手动遍历eg.exceptions - 未被任何
except*匹配的异常会继续向上抛出，所以宽泛类型（如except* Exception）应放在最后
TaskGroup + except* 组合必须满足的运行条件
asyncio.TaskGroup 不是“开箱即用”的工具，它依赖事件循环处于活跃状态，且上下文严格受限。
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 只能在
async with asyncio.TaskGroup() as tg:块内调用tg.create_task()，外部调用报RuntimeError: TaskGroup is closed - 不能在块内直接
await单个任务，否则破坏结构化并发语义，导致取消信号无法传播 - pytest 中使用需启用
asyncio_mode = "strict"，并确保 fixture 或 test 函数是async def，否则静默降级为同步执行
常见错误：把 gather 的习惯套到 TaskGroup 上
很多人以为 TaskGroup 是 gather 的增强版，结果写出不可靠代码。
-
asyncio.gather默认只抛第一个异常，其余任务仍在后台运行；TaskGroup则强制取消所有子任务，但前提是每个协程都实现了清理逻辑（如async with httpx.AsyncClient()） - 别依赖
[t1.result(), t2.result()]的顺序对应原始调用顺序——TaskGroup不保证执行完成顺序 - 若协程里用了
time.sleep()而非await asyncio.sleep()，整个事件循环会被阻塞，TaskGroup的取消机制完全失效
真正的难点不在语法，而在于协程是否“可取消”——HTTP 客户端没设 timeout、文件写入没包在 async with 里、数据库连接没显式 close，这些都会让 TaskGroup 的取消变成假动作。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
