Java中保留异常原始堆栈的关键是直接re-throw原始异常对象（如throw e;），避免新建异常；若需包装，应使用带cause参数的构造函数，并辅以日志和业务上下文。
Java中 throw 重新抛出异常时，默认会调用 fillInStackTrace()，覆盖原始堆栈信息。若想保留原始堆栈，关键不是“不调用”，而是**避免触发默认的堆栈重写**——最直接有效的方式是直接 re-throw 原始异常对象，不做新建操作。
直接 throw 原异常（推荐）
只要不 new 新异常，而是复用捕获到的异常实例，JVM 不会重置堆栈：
- ✅ 正确：`throw e;`（e 是 catch 中的原始异常）
- ❌ 错误：`throw new RuntimeException(e);` 或 `throw new MyException(e.getMessage());` —— 这会创建新异常，丢失原始堆栈起点
使用 initCause 或构造函数传 cause（需谨慎）
如果必须包装异常（如统一异常类型），应使用支持 cause 的构造函数，并确保原始异常作为 cause 传入：
- ✅ 推荐：`throw new BusinessException("业务失败", e);`（前提是 BusinessException 有 `Throwable cause` 构造器）
- ⚠️ 注意：这种写法虽保留了 cause 堆栈，但外层异常的堆栈起点仍是当前 throw 位置；调试时需展开 cause 才能看到原始源头
禁用 fillInStackTrace（非常规，不推荐）
可通过反射或继承并重写方法来跳过堆栈填充，但破坏了异常语义，且在现代 JDK（尤其是模块化后）可能受限：
立即学习“Java免费学习笔记（深入）”；
- ❌ 不建议：`e.fillInStackTrace(); return e;` 没有意义；`e.setStackTrace(new StackTraceElement[0]);` 会清空堆栈
- ❌ 避免反射修改：`Throwable::setStackTrace` 可设为空或自定义，但丢失关键诊断信息，降低可维护性
日志 + 异常链（生产环境实用策略）
真正影响排查的是“能否追溯到最初出错点”。除堆栈外，补充上下文更可靠：
- 在 catch 块中记录原始异常完整堆栈（用 `log.error("", e)`）
- 包装异常时，保留关键业务上下文（如订单ID、用户ID），而非仅依赖堆栈
- 利用 `e.getCause()` 和 `e.getSuppressed()` 配合多层异常链分析
不复杂但容易忽略：保留原始堆栈的本质，是别新建异常；需要增强语义就用 cause 包装，再配合日志和上下文，比强行“冻结堆栈”更健壮。
