会，raise from 会保留原始异常的 traceback 并设为 __cause__，用“the above exception was the direct cause of the following exception:”连接；而普通 raise 不保留。
raise from 会保留原始异常的 traceback 吗？
会，而且这是它和普通 raise 最关键的区别。用 raise new_exc from orig_exc 时，Python 会把 orig_exc 记为 __cause__，并在最终报错中同时显示两个异常的 traceback，中间用 The above exception was the direct cause of the following exception: 连接。
常见错误现象：只写 raise new_exc，结果原始异常信息（比如文件路径、JSON 解析位置）完全丢失，调试时只能看到最外层的“出错了”，不知道哪一行、为什么错。
- 必须显式写
from，否则不构成异常链 -
orig_exc必须是Exception实例，不能是类名或字符串 - 如果
orig_exc是None，Python 会设为__cause__ = None，但依然显示链式结构
什么时候该用 raise from 而不是 except + raise？
当你要在捕获异常后「包装」它、补充上下文，又不想丢掉原始根因时，就该用 raise from。典型场景包括：封装底层库调用、统一 API 错误码、转换异常类型但保留现场。
反例：只是想记录日志然后重新抛出，用 raise（不带 from）就够了；强行加 from 反而让 traceback 变冗长。
- 推荐：
raise ValueError("配置项 'timeout' 必须为正数") from e（e是ValueError或TypeError） - 不推荐：
raise RuntimeError("处理失败") from e，其中e是KeyboardInterrupt—— 用户中断不该被包装成业务异常 - 注意：若在
except块里没保存exc引用（如直接写raise ValueError() from e但e未定义），会报NameError
raise from 和 __suppress_context__ 的关系
默认情况下，raise from 会自动设 new_exc.__suppress_context__ = True，这意味着 Python 不会再把隐式上下文（比如 except 块里发生的另一个异常）混进来。这是好事——避免 traceback 里出现无关的“中间异常”。
但如果你手动设置了 new_exc.__suppress_context__ = False，又用了 from，行为就变成混合模式：既显示 __cause__，又显示 __context__，容易让人困惑。
- 绝大多数情况，别碰
__suppress_context__，让它保持默认True - 只有当你明确需要保留隐式上下文（极少见），才设为
False，且必须配合from使用才有意义 - 检查方式：
print(exc.__cause__)和print(exc.__context__)可分别看到显式/隐式链
实际例子：解析 JSON 配置时包装异常
假设你读取一个配置文件，底层用 json.loads()，但想对外暴露更友好的错误提示，同时保留原始 JSON 解析位置：
try:
data = json.loads(content)
except json.JSONDecodeError as e:
raise ValueError(f"配置文件格式错误（第 {e.lineno} 行，第 {e.colno} 列）") from e
这样调用方看到的 traceback 里，先有 json.JSONDecodeError 的详细位置，再有你自定义的 ValueError 提示。如果去掉 from e，就只剩最后一行，根本找不到错在哪。
容易被忽略的一点：from 后面的异常对象必须还“活着”。如果在 except 块里做了耗时操作（比如网络请求），之后再 raise ... from e，e 仍有效；但如果在另一个函数里试图复用这个 e，可能因引用丢失而出错。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
