应优先使用 raise … from e 保留原始异常上下文，raise 会丢失根因，raise 无参数才重抛当前异常；__cause__ 显式声明因果，__context__ 隐式记录处理中异常，二者语义与监控兼容性不同。
raise 直接抛出异常，不保留原始错误上下文
当你只写 raise（不带参数）时，python 会重新抛出当前正在处理的异常，保留其原始 traceback；但若写 raise ValueError("bad") 这种带新异常的，就完全丢弃了之前那个异常的信息——哪怕它才是问题根源。
常见错误现象：在 except 块里捕获了一个 KeyError，想包装成更语义化的错误，却直接 raise ValueError("config missing")，结果 traceback 里看不到原始的 key 名和位置。
- 适合场景：你确定原始异常无关紧要，或已在日志中记录过
- 性能影响：无额外开销，但调试成本上升
- 典型误用：
except KeyError: raise ConfigError("key not found")—— 丢失了具体哪个 key 没找到
raise from 显式声明异常因果关系
raise NewException(...) from original_exc 会把原始异常设为新异常的 __cause__，Python 在打印 traceback 时自动显示 “The above exception was the direct cause of the following exception:”，形成可追溯的链路。
使用场景：封装底层错误（如数据库驱动抛出 psycopg2.OperationalError），向上层暴露业务异常（UserCreationFailed），同时保留根因。
立即学习“Python免费学习笔记（深入）”；
- 原始异常可以是任意对象，甚至
None（此时等价于raise ... from None，抑制异常链） - 如果
from后面是None，Python 不会显示 “caused by” 提示，但也不会关联 traceback - 注意：不能在没有活跃异常的上下文中用
raise ... from e，否则报RaiseError: No active exception to reraise
隐式异常链：except 中 raise 新异常时自动触发
当在 except 块里直接 raise SomeOtherError（不带 from），Python 默认把刚捕获的异常设为新异常的 __context__。这属于“隐式链”，traceback 末尾会提示 “During handling of the above exception, another exception occurred:”。
它和 from 的关键区别在于语义：隐式链表示“处理过程中又出了错”，而 from 表示“这个错是由那个错导致的”。调试时前者容易让人误判执行路径。
- 示例：
except ValueError: process_data(); raise TypeError()→ 隐式链，因为process_data()报了错 - 如果你本意是“ValueError 导致了 TypeError”，就该显式写
raise TypeError() from e - 某些 ide 或日志工具只解析
__cause__，忽略__context__，导致隐式链被静默丢弃
怎么选：看要不要让调用方看到原始异常细节
决定用 raise 还是 raise from 的核心，不是语法习惯，而是接口契约——下游是否需要知道底层发生了什么。比如写 SDK 时，用户传了非法参数，你抛 raise InvalidArgumentError() from e，他们才能区分是自己错了，还是网络请求底层 ssl 握手失败了。
- 对外暴露的库/服务：优先
raise ... from e，除非明确要屏蔽细节（如安全敏感字段） - 内部模块间调用：可用隐式链，但建议统一用
from，避免语义混淆 - 测试时验证异常链：
assert exc.__cause__ is not None或检查exc.__context__
真正容易被忽略的是：__cause__ 和 __context__ 是两个独立属性，混用会导致 traceback 层级混乱，且部分错误监控系统（如 sentry）默认只上报 __cause__。