<p>except* 不能替代普通 except，因为它仅处理 ExceptionGroup，对单个异常直接报语法错误；必须与 ExceptionGroup 配合使用，不递归解包嵌套组，且不走 MRO 查找子类。</p>
Python 3.11 的 except* 为什么不能替代普通 except
因为 except* 只处理 ExceptionGroup，对单个异常直接报 SyntaxError: invalid syntax —— 它不是“增强版 except”，而是专为并发异常聚合设计的语法糖。
常见错误现象：except* ValueError: 在没抛 ExceptionGroup 的代码里直接写，解释器当场拒绝；或者误以为它能捕获子类异常（实际只匹配组内成员，不走 MRO 查找）。
-
except*必须和ExceptionGroup配合使用，单独抛ValueError()不触发任何except*分支 - 一个
except*块会尝试匹配组内所有未被前面分支捕获的异常，不是“只抓第一个” - 如果组里混了
ValueError和TypeError，而你只写了except* ValueError:，剩下的TypeError会继续向上冒泡，不会自动进except Exception:
怎么安全地从 asyncio.gather(..., return_exceptions=True) 迁移到 except*
旧写法靠 return_exceptions=True 把异常塞进结果列表，再手动遍历判断；新写法用 except* 更直接，但要注意：必须确保 gather 真的抛出 ExceptionGroup，而不是静默吞掉。
- 默认情况下
asyncio.gather()遇到第一个异常就停，要显式传return_exceptions=False（默认值）并配合except*才生效 - 实际得这么写：
try: await asyncio.gather(a(), b(), c()) except* ValueError as eg: ...—— 注意这里没加return_exceptions=True，因为gather在任一协程出错时会自动包装成ExceptionGroup抛出 - 如果你用了
return_exceptions=True，结果是[None, ValueError(), None]这种混合列表，except*完全不适用
ExceptionGroup 的嵌套结构会让 except* 失效吗？
不会失效，但匹配逻辑变复杂：嵌套的 ExceptionGroup 被视为普通异常对象，except* 只展开最外层，不会递归解包。
立即学习“Python免费学习笔记（深入）”；
例如：ExceptionGroup("outer", [ValueError(), ExceptionGroup("inner", [TypeError()])])，except* ValueError: 能捕获第一个，except* TypeError: 不会命中，因为 TypeError 被包在内层组里，对外不可见。
- 想让内层异常也被
except*捕获，得手动调用eg.split(TypeError)或用except* BaseException:先接住再拆 -
ExceptionGroup的__cause__和__context__不影响except*匹配，只影响raise时的 traceback 展示 - 用
eg.subgroup(TypeError)可以提取所有匹配的异常（含嵌套组里的），但它返回新ExceptionGroup，不是扁平列表
Pytest 或日志框架里怎么避免 ExceptionGroup 被当成“奇怪的异常”打爆控制台
很多工具没适配 3.11+ 的异常组，遇到 ExceptionGroup 会直接调 str() 或 repr()，输出一堆嵌套括号和地址，看不出真实错误。
- 在 pytest 中，升级到 ≥7.4 版本才支持友好展示；低于该版本建议临时加
--tb=short避免刷屏 - 自定义 logger 时，检查
record.exc_info是否为ExceptionGroup，如果是，用eg.exceptions手动遍历每条异常调traceback.format_exception() -
logging.exception()在 3.11.5+ 修复了基础兼容，但若用了第三方 handler（比如 Sentry SDK 旧版），仍可能丢掉部分异常信息——得确认其是否调用了eg.walk()
真正麻烦的是跨进程或序列化场景：pickle 能存 ExceptionGroup，但反序列化后若目标环境是 Python ImportError。别把异常组当数据传给老版本解释器。
