<p>Python 3.11 的 ExceptionGroup 和 except* 让多级异常并行保留上下文，结构化分组所有子异常并支持精准列级 traceback；PEP 657 提供每层异常的 col_offset 定位；ExceptionTable 编译期优化避免栈膨胀；但 C 扩展、-O 模式或调试器会使其降级失效。</p>
Python 3.11 的 ExceptionGroup 和 except* 怎么让多级异常不丢失上下文
旧版 Python 遇到多个并发异常（比如 asyncio.gather 中多个任务失败），只会抛出第一个异常，其余被静默吞掉——你根本不知道还有别的错误在同时发生。Python 3.11 引入 ExceptionGroup 和 except*，让所有异常并行保留，回溯里会清晰列出每个子异常的完整 traceback。
关键点在于：它不是简单堆叠错误，而是结构化分组。比如 async with TaskGroup() 抛出的异常，顶层是 ExceptionGroup，内部每个元素都是独立的 ValueError 或 TimeoutError，各自带自己的文件、行号、列偏移。
- 必须用
except*捕获，普通except无法匹配ExceptionGroup -
except* ValueError只处理组内所有ValueError，不影响其他类型 - 回溯输出里每条异常都带独立的
^^^^^和~~~~~标注，互不干扰
为什么 PEP 657 的列级标注在多级异常中更关键
多级异常常出现在嵌套调用或动态构造的代码路径中（如模板渲染 + 数据校验 + 网络请求），错误位置容易跨多层函数。Python 3.11 的 PEP 657 不仅对顶层异常精准定位，还会把每个子异常的 col_offset 和 end_col_offset 注入 traceback——这意味着你能看到 KeyError 出现在 data['user']['profile']['avatar'] 的 'avatar' 上，而不是整行糊掉。
- 如果某子异常来自
exec()字符串，且未传filename参数，该层级的列信息会退化为 0，但其他层级仍保持精确 - Jupyter Lab 和 VS Code 的错误高亮已适配该机制，点击波浪线可直接跳转到出错 token
- 自定义
sys.excepthook能通过exc.__traceback__.tb_frame.f_lineno和.f_colno获取每级异常的列号
ExceptionTable 如何避免多级异常处理时的栈膨胀
旧版 try/except 嵌套越深，运行时维护的块栈（block stack）越长，每次进入/退出都要执行 SETUP_FINALLY 和 POP_BLOCK。Python 3.11 的 co_exceptiontable 是编译期生成的只读表，无论嵌套多少层，无异常路径下都不增加栈帧开销——这对高频触发多级异常的场景（如微服务网关批量校验）尤为明显。
立即学习“Python免费学习笔记（深入）”；
- 嵌套深度影响的是
co_exceptiontable大小，而非运行时性能；查表时间复杂度仍是 O(1) 级别 - 但若某层
except块里做了重操作（如序列化整个ExceptionGroup），瓶颈就转移到那里，和 ExceptionTable 无关 - 用
dis.dis()查看函数字节码，末尾出现的ExceptionTable:区域会列出所有嵌套跳转规则，比如L10 to L20 -> L30 [1]
调试时最容易忽略的兼容性断层
多级异常回溯的“帮助”前提是整个调用链都在 Python 3.11 解释器下运行。一旦中间混入 C 扩展（如 NumPy 的 ufunc 错误）、或用了 -O 启动（禁用特化解释器）、或被调试器 hook（sys.settrace），ExceptionGroup 会降级为普通 Exception，PEP 657 的列信息也会失效——此时你看到的仍是整行模糊标注。
真正难排查的不是语法错误，而是那种“看起来像单点故障，实际是三处并发失败”的场景。Python 3.11 让你一眼看清全貌，但前提是别在关键路径上绕过它的机制。
