java中直接throw捕获的异常可保留原始堆栈，无需新建异常对象；日志应使用log.warn("msg", e)而非字符串拼接；addsuppressed()用于附加抑制异常，非重抛替代；自定义异常须在构造函数中调用super(msg, cause)传递cause。
Java中用throw直接抛出捕获的异常就能保留原始堆栈
只要不新建异常对象，而是把捕获到的异常原样throw出去，JVM 就会保持它最初的堆栈轨迹。这是最常用也最安全的做法，不需要额外操作。
- ✅ 正确：
catch (IOException e) { throw e; }—— 堆栈从最初抛出处开始，中间catch位置不会插入新帧 - ❌ 错误：
catch (IOException e) { throw new RuntimeException(e); }—— 这会创建新异常，原始堆栈被包进cause，顶层堆栈变成当前throw行 - ⚠️ 注意：
throw e;要求e的类型在方法声明的throws列表中，否则编译报错；若不想改声明，得用RuntimeException包装（但会丢失原始堆栈起点）
想加日志又不破坏堆栈？用log.debug("xxx", e)而不是log.debug("xxx " + e)
很多人在catch里先打印再throw，结果手抖拼字符串，导致原始异常信息被转成toString()丢掉堆栈。日志框架（如SLF4J、Log4j）对第二个Throwable参数有专门处理逻辑，能完整输出堆栈而不污染原始轨迹。
- ✅ 安全：
log.warn("读取配置失败", e); throw e; - ❌ 破坏堆栈线索：
log.warn("读取配置失败: " + e); throw e;——e.toString()只输出类名+消息，没有堆栈，排查时看不到哪行代码真正出问题 - ? 补充：如果用了
try-with-resources，且资源关闭时也抛异常，JVM 会把关闭异常作为suppressed附加到主异常上，不影响原始堆栈主体
Throwable.addSuppressed()适合多异常合并场景，不是重抛替代方案
这个方法不是为了“重抛”，而是当一个异常已经抛出、但后续清理过程又发生另一个异常时，把后者作为被抑制异常附着上去。它和throw e;解决的是完全不同的问题。
- ✅ 合理用法：在
finally或close()里捕获新异常，调用originalException.addSuppressed(newException)，再throw originalException - ❌ 误用：
catch (e) { e.addSuppressed(new RuntimeException("fake")); throw e; }—— 没意义地往原始异常上硬塞无关信息，反而干扰真实错误定位 - ⚡ 性能提示：
addSuppressed()内部会复制堆栈快照，频繁调用有开销；生产环境别在循环里滥用
自定义异常继承RuntimeException时，别忘了调用super(message, cause)
如果封装了业务异常并希望保留原始异常链，构造函数里必须显式把cause传给父类。漏掉这一步，getCause()返回null，上游即使用throw e;也救不回堆栈上下文。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确：
public class BizException extends RuntimeException { public BizException(String msg, Throwable cause) { super(msg, cause); } } - ❌ 隐患写法：
public BizException(String msg, Throwable cause) { super(msg); }——cause丢了，原始异常彻底断链 - ? 检查技巧：在调试时打个断点，调用
e.getCause()确认是否为预期异常；或者用e.printStackTrace()看输出里有没有Caused by:块
cause的操作，都会悄悄截断排查线索。 
