应使用 raise NewException() from original_exc 保留原始异常上下文，显式设置 __cause__ 并触发「直接原因」语义；避免 from None 或省略 from，否则导致异常链断裂、调试困难。
Python 中用 raise ... from ... 保留原始异常上下文
直接用 raise NewException() from original_exc，就能在抛出新异常的同时保留原始异常的 traceback。这比单纯 raise NewException() 强得多——后者会丢失原始错误位置和堆栈，调试时根本找不到根因。
常见错误是写成 raise NewException() from None 或漏掉 from 直接二次抛出，结果变成「异常链断裂」，__cause__ 为空，只剩 __context__（隐式回溯），可读性差很多。
- 显式
from触发的是「直接原因」语义，__cause__属性被设置，__suppress_context__ = True - 没写
from的二次抛出会保留__context__，但容易和意外嵌套混淆 - 想彻底切断关联才用
from None，比如封装底层异常时有意隐藏细节
什么时候该用 raise ... from ... 而不是 raise ...
核心判断点：调用方是否需要知道「这个错误是怎么一步步发生的」。比如数据库操作失败后转成业务异常 OrderCreationFailed，但运维仍需看到底层是 psycopg2.OperationalError 连不上库。
典型场景包括：
- 框架层包装底层 SDK 异常（如把
requests.RequestException转为ApiClientError） - 业务逻辑中将校验失败统一转为
ValidationError，同时带上原始字段验证异常 -
异步任务里把
concurrent.futures.TimeoutError包装成更明确的TaskExecutionTimeout
raise ... from ... 和 raise ... from None 的行为差异
关键区别在解释器如何展示 traceback。前者默认显示两段堆栈（原始异常 + 新异常），后者只显示新异常，原始信息彻底丢弃。
示例对比：
try:
int("abc")
except ValueError as e:
raise RuntimeError("转换失败") from e
输出含 The above exception was the direct cause of the following exception:；而 from None 会删掉前半段，只剩 RuntimeError 单层堆栈。
- 不加
from：保留隐式__context__，但会被raise新异常覆盖，容易误判因果 - 加
from None：设__cause__ = None且__suppress_context__ = True，完全隔离 - 生产环境慎用
from None，除非你明确要屏蔽原始线索
注意 __cause__ 和 __context__ 的自动赋值规则
Python 在异常传播中会自动填充 __context__，但 __cause__ 必须显式用 from 设置。如果既没写 from 又在 except 块里 raise，解释器会把当前异常设为下一个异常的 __context__，而非 __cause__。
这意味着：没用 from 的链式抛出，traceback 里不会出现「direct cause」提示，只有「During handling of the above exception, another exception occurred」——这种提示容易让人误以为是两个独立异常。
- 想表达「因为 A 所以 B」，必须用
from A -
__cause__是开发者意图的显式声明，__context__是解释器自动维护的执行流快照 - 检查异常对象时，优先看
exc.__cause__是否非空，它比__context__更可靠
from。异常链一断，查问题的时间可能翻倍。 
