在Python中，当一段代码捕获了异常却又抛出了另一个异常，解释器并不会简单地丢弃原本的出错信息，而是会通过特定的机制把前后两次异常现场连接起来，形成所谓的异常链。这种机制让开发者在排查嵌套调用或封装良好的库代码时，依然能够看到最初引发问题的根因，而不是只看到最外层被包装过的错误。
异常链的基本类型
Python的异常链主要分为两种：显式链和隐式链。显式链通过raise new_exc from original_exc语法建立，此时新异常的__cause__属性会直接引用原异常，语义上表示新异常是由原异常明确导致的。隐式链则发生在except块中直接raise另一个异常而未使用from时，解释器自动把当前处理的异常存入新异常的__context__属性，表示两者在控制流上先后发生，但不一定是严格的因果关系。
这两种机制的存在，是为了解决早期Python版本中异常被覆盖导致调试困难的问题。在Python 3之前，如果在except中抛出新异常，原始异常往往丢失。而现在，无论是__cause__还是__context__，都会被traceback模块在打印时利用，形成多段堆栈输出。理解它们的区别，有助于在编写底层库时有意暴露根因，或在应用层有意屏蔽实现细节。
traceback对象的生成过程
当异常被引发，Python解释器会在当前调用栈上逐帧收集信息，构造一个链表式的traceback对象。每一个traceback帧（traceback.TracebackException或C层面的PyTracebackObject）记录了对应的代码文件、行号、函数名以及局部变量快照。若异常对象带有__cause__或__context__，traceback模块在格式化输出时会递归地处理这些关联异常，把它们的traceback也依次打印出来。
具体来看，traceback.format_exception在内部会检查异常对象的__cause__：如果存在，则先格式化因果链上的上游异常，并在中间插入“The above exception was the direct cause of the following exception”之类的提示；若只有__context__且__cause__为空，则打印“During handling of the above exception, another exception occurred”。这种分层输出正是异常链可见性的来源。
try:
raise ValueError("原始错误")
except ValueError as e:
# 隐式链：新异常__context__指向e
raise RuntimeError("处理时出错")
上面这段代码运行后，控制台会显示ValueError的traceback，紧接着提示在处理上述异常时发生了另一个异常，再给出RuntimeError的traceback。而如果改成raise RuntimeError("处理时出错") from e，输出则会明确标注前者是后者的直接原因。
利用traceback模块主动提取链路
除了依赖解释器默认的打印，我们也可以在日志系统中用traceback.TracebackException类来结构化地提取整条异常链。这个类能把异常及其因果、上下文全部捕获为一个可序列化对象，方便存入日志或发送到监控平台。
下面的示例展示了如何递归遍历__cause__和__context__，把每一层异常的类型与消息都打印出来，而不依赖标准错误输出。
import traceback
def show_chain(exc):
# 提取异常链并逐层展示
te = traceback.TracebackException.from_exception(exc)
for line in te.format():
print(line, end="")
# 若存在显式原因则继续追溯
if exc.__cause__:
print("--- 因果链上游 ---")
show_chain(exc.__cause__)
elif exc.__context__:
print("--- 隐式上下文 ---")
show_chain(exc.__context__)
try:
try:
raise KeyError("缺失键")
except KeyError as ke:
raise IndexError("索引越界") from ke
except IndexError as ie:
show_chain(ie)
运行后，程序会先输出IndexError及其堆栈，再通过__cause__进入KeyError的堆栈。这种写法比单纯print(exc)信息量大得多，特别适合在异步任务或后台worker中收集故障现场。
异常链使用中的常见误区
一个容易被忽略的问题是，在except块中使用raise from None会显式切断异常链。这在某些场景（如不想暴露内部实现）是合理的，但如果滥用，会让调用方完全看不到根因。另外，有些人误以为只要捕获后再抛出同名异常就能保留链路，实际上重新raise同一个异常对象才会保留，新建实例则会开启新的上下文。
还有一个性能相关的细节：traceback对象会持有栈帧引用，若长期把异常对象放在全局变量或闭包中，可能导致内存无法释放。因此在Web请求结束或任务完成后，应及时丢弃不再需要的异常实例，或在记录日志后主动解绑__traceback__属性。
| 机制 | 建立方式 | 属性 | 输出提示特征 |
|---|---|---|---|
| 显式链 | raise B from A | __cause__ | direct cause of the following |
| 隐式链 | except中raise B | __context__ | During handling of the above |
| 断链 | raise B from None | __cause__为None | 不显示上游异常 |
掌握这些差异后，在封装SDK或中间件时，就能有意识地选择是否暴露底层异常，让产品的错误提示既友好又不失调试价值。