正确做法是在except块中直接写raise（不带参数），可完整保留原始异常的类型、值和traceback；若需添加上下文，应使用raise new_exc from original_exc实现链式异常。
用 raise 不带参数保留原始 traceback
在 except 块中直接写 raise（不带任何参数），python 会原样重新抛出当前正在处理的异常，包括原始的 traceback、类型、值和完整的调用栈。这是最干净、最推荐的方式。
常见错误是写成 raise e 或 raise sys.exc_info()[1] —— 这会丢失原始 traceback，只保留异常对象本身，导致调试时看不到最初的出错位置。
- ✅ 正确：
raise（空 raise） - ❌ 错误：
raise e（e 是捕获的异常变量） - ❌ 错误：
raise type(e), e, e.__traceback__（Python 3 已废弃三元 raise 语法）
想加额外信息又不破坏原始 traceback？用 raise ... from
如果需要在保留原始异常的基础上附加上下文（比如说明“这个异常发生在处理用户请求时”），应该用 raise new_exc from original_exc。这会生成一个链式异常（__cause__），原始 traceback 完整保留，且解释更清晰。
注意：不要用 raise new_exc from None，那会显式切断链路，反而丢掉原始 traceback。
- 适合场景：包装底层异常为业务异常，如把
requests.RequestException转为自定义ApiConnectionError - 效果：
raise ApiConnectionError("failed to fetch user") from e会在 traceback 末尾显示 “The above exception was the direct cause of the following exception:” - 避免手动拼接
str(e)到新异常里——原始异常的 message 和 args 仍可访问，无需覆盖
临时修改 traceback（极少数需要）用 traceback.print_exception + sys.excepthook
标准库不提供“在原 traceback 上追加几行”的接口。所谓“附加额外 traceback”，实际需求往往是：记录日志时多打点上下文，或调试时临时注入位置信息。这时候不该动 traceback 对象本身，而应控制输出方式。
- 调试时可用
import traceback; traceback.print_exception(*sys.exc_info())手动打印，再补一行print("Context: user_id=123, step='validation'") - 全局定制异常输出？重设
sys.excepthook，但要注意它只影响未捕获异常，对except内部无效 -
exc.__traceback__ = traceback.with_traceback(...)是危险操作，容易引发引用循环或状态不一致，不建议在生产代码中使用
为什么 raise 空语句能保留 traceback？
因为 Python 的异常上下文（包括 __traceback__、__cause__、__context__）在进入 except 块时就已绑定到当前帧的隐式异常变量上。空 raise 会复用这个隐式状态，而不是新建异常对象。
这点容易被忽略：只要没在 except 中执行过其他 raise，哪怕中间调用了函数、修改了变量，空 raise 依然安全可靠。
- 例外情况：在
except中又触发了新异常（比如日志写入失败），此时隐式异常会被覆盖 —— 所以加日志要放在raise前，且确保日志逻辑不会抛异常 - 验证方法：打印
sys.exc_info()，看第三个元素（即 traceback 对象）是否非None