python 3.12+ 中 traceback.print_exception() 默认 chain=true 可完整打印异常链（__cause__ 和 __context__），而 print(e) 或 logging.exception() 不展开链；需用 exc_info=true 或手动递归遍历链属性提取结构化信息。
Python 3.12+ 中用 traceback.print_exception() 打印完整异常链
默认的 except Exception as e: 只捕获当前异常，不自动展开 __cause__ 或 __context__ 链。要看到完整的“谁抛的、谁接的、谁又 raise from 的”，得手动调用 traceback.print_exception() 并传入 chain=True（这是默认值，但显式写出更稳妥）。
常见错误是只用 print(e) 或 logging.exception() ——后者虽会打 traceback，但默认只显示当前异常，不递归展开 cause/context。
-
traceback.print_exception(type(e), e, e.__traceback__, chain=True)是最直接的方式 - 若在日志中记录，用
logger.error("msg", exc_info=True)——它等价于chain=True，能正确展开链 - 注意：
exc_info=True必须传给 logging 方法本身，不是写成exc_info=e
手动遍历 __cause__ 和 __context__ 构建自定义输出
当需要结构化处理（比如提取每个异常的类型、消息、文件位置），不能只依赖打印函数，得自己递归访问异常对象的链属性。
__cause__ 是显式用 raise ... from ... 创建的；__context__ 是隐式在 except 块中又 raise 新异常时自动关联的。两者可能同时存在，且可嵌套多层。
- 优先检查
e.__cause__，有则递归处理；没有再看e.__context__（但仅当e.__suppress_context__ is False） - 每层都要重新获取
__traceback__，不能复用外层的 traceback 对象 - 避免无限循环：需记录已见过的异常 id，防止循环引用（极少见，但可能出现在自定义异常中）
为什么 repr(e) 或 str(e) 完全不显示异常链
repr() 和 str() 只作用于当前异常实例本身，完全忽略其 __cause__、__context__、__traceback__ 等元信息。这是设计使然——它们只负责“这个异常长什么样”，不负责“这个异常怎么来的”。
所以以下写法毫无意义：
except Exception as e:
print(repr(e)) # ← 只输出当前异常的字符串表示，链信息彻底丢失
同理，json.dumps({"error": str(e)}) 这类序列化也拿不到链，必须提前把链结构转成 dict 再序列化。
兼容旧版本 Python（
Python 3.12 改进了 traceback.format_exception() 的默认行为，但 3.11 及更早版本中，chain 参数默认为 True，实际行为一致。真正要注意的是某些第三方库（如 rich.traceback、IPython）可能默认关闭链展开，或需要额外配置。
- 用
rich.traceback.install(show_locals=True, suppress=...)时，确保没传max_frames=0或suppress错误地过滤掉中间异常 - 在 pytest 中，
--tb=short会压缩链，改用--tb=long或--tb=native - Django 的 DEBUG=True 页面会展示完整链，但生产环境
LOGGING配置里若用了自定义 formatter，需确认是否调用了formatException()
异常链不是自动“附着”在日志里的东西，它需要明确触发和显式消费。最容易被忽略的点是：以为 logging.exception() 就够了，结果上线后发现上游异常被吞掉了一层——那往往是因为某处写了 raise NewError() from None，或者 __suppress_context__ = True 被悄悄设上了。
