Python 异常链（exception chaining）是如何工作的？
Python异常链通过__cause__（显式raise...from）和__context__（隐式未处理异常捕获）建立可追溯因果关系，调试时默认展示双堆栈，支持日志记录与语义化错误封装。
Python 异常链通过两个核心属性实现错误上下文的显式与隐式关联：`__cause__` 和 `__context__`。它不是简单地“抛出一个异常”，而是建立可追溯的因果关系，让调试时既能看清当前问题，也能快速定位原始诱因。
显式链接靠 raise 
... from
当你写 raise NewError("xxx") from orig_exc，Python 会把 orig_exc 赋值给新异常的 __cause__ 属性。这表示“这个新异常是**直接由**原异常导致的”。
- traceback 中会明确显示："The above exception was the direct cause of the following exception"
- 调用方可通过
e.__cause__直接访问原始异常对象 - 用
raise NewError(...) from None可主动切断链，避免干扰
隐式捕获靠 __context__
如果没写 from，但当前作用域里刚发生过一个未被处理的异常（比如在 except 块里又抛了另一个异常），Python 会自动把那个异常存进新异常的 __context__。
- 这属于“意外连带”的上下文，不表示明确因果，只说明“刚才那里也出了事”
- traceback 会提示："During handling of the above exception, another exception occurred"
- 它比
__cause__优先级低，__cause__存在时不会显示__context__
实际调试中怎么用
异常链的价值在日志和终端输出里立刻体现：
- 打印异常时，默认同时展示
__cause__的完整 traceback（两段堆栈） - 用
logging.exception()记录，会自动包含整个链 - 自定义异常类中，可重写
__str__或添加方法，主动暴露__cause__的关键信息 - API 封装层常用它把底层错误（如数据库连接失败）转为语义清晰的应用错误（如“用户服务不可用”），又不丢根
