Python 3.11 的异步异常处理优化依赖 TaskGroup + ExceptionGroup + except* 组合机制，而非改写 await；需显式使用 async with asyncio.TaskGroup() 替代 asyncio.gather，以实现可预测、可分类、可清理的并发异常管理。
Python 3.11 的异步异常处理优化不是靠“改写 await”实现的，而是通过 TaskGroup + ExceptionGroup + except* 这套组合机制，把原本容易失控的并发异常变成可预测、可分类、可清理的状态。升级版本本身不自动生效，必须显式改用新结构。
为什么 asyncio.gather 会丢异常和资源
当你用 asyncio.gather 并发跑多个协程，其中一个抛出 httpx.HTTPStatusError，默认行为是：
- 立刻停止等待其他任务，但已启动的协程不会被取消——比如正在写临时文件的协程可能继续执行到一半就中断，文件没关、锁没释放
- 只抛出第一个异常，其余任务的错误信息彻底丢失
- 即使设
return_exceptions=True，你也得手动遍历结果列表检查每个.exception()，无法按类型聚合处理
这不是 bug，是设计使然：gather 本质是“并行收集结果”，不承担生命周期管理责任。
用 async with asyncio.TaskGroup() 替换 gather
TaskGroup 强制你进入结构化并发模型：所有子任务共享上下文，异常发生时先发取消信号，再等它们走完 async with 或 finally 清理逻辑，最后才聚合抛出 ExceptionGroup。
立即学习“Python免费学习笔记（深入）”；
必须满足这些条件才能启用该机制：
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
- 只能在
async with asyncio.TaskGroup() as tg:块内调用tg.create_task()，外部调用会报RuntimeError: TaskGroup is closed - 不能在块内直接
await单个任务，否则破坏结构约束 - 结果顺序不保证，别依赖
[t1.result(), t2.result()]的索引对应原始任务
示例中若 fetch_user(1) 和 fetch_user(3) 都抛 httpx.HTTPStatusError，except* 能一次性捕获这两个异常实例：
try:
async with asyncio.TaskGroup() as tg:
task1 = tg.create_task(fetch_user(1))
task2 = tg.create_task(fetch_user(2))
task3 = tg.create_task(fetch_user(3))
results = [task1.result(), task2.result(), task3.result()]
except* httpx.HTTPStatusError as eg:
print(f"共 {len(eg.exceptions)} 个 HTTP 错误")
except* asyncio.TimeoutError as eg:
print(f"共 {len(eg.exceptions)} 个超时")ExceptionGroup 捕获必须用 except*，不能用普通 except
ExceptionGroup 是全新异常类型，继承自 BaseException，但**不继承自 Exception**。这意味着：
-
except Exception:完全捕获不到ExceptionGroup，会直接向上冒泡导致程序崩溃 -
except* (ValueError, TypeError):是唯一合法语法，括号里必须是具体异常类，不能写except* Exception: - 嵌套
ExceptionGroup时，except*只匹配最外层类型，内部异常需递归访问eg.exceptions
如果你需要兜底捕获所有异常（包括 ExceptionGroup），只能写 except BaseException:，但要小心别吞掉 KeyboardInterrupt 或 SystemExit。
TaskGroup 不提速，但让错误变得“可调试”
TaskGroup 本身不减少 CPU 或事件循环开销，它解决的是异常传播的不可控性。最容易被忽略的一点是：它要求你重新思考任务边界。
比如你习惯把数据库查询、缓存更新、日志记录打包进一个协程里，一旦这个协程在中间某步失败，TaskGroup 会取消整个协程，但它的 finally 仍会执行——这看似安全，实则掩盖了“本应分步提交”的问题。真正健壮的做法是让每个 tg.create_task() 对应一个语义清晰、可独立失败/重试的单元，而不是把一堆副作用塞进单个协程。
