什么是 Suppressed Exception：不是“被吞了”，而是被 JVM 主动归档了
Suppressed Exception 不是异常丢失，而是 JVM 在「必须只抛一个异常」的前提下，把次要异常悄悄附加到主异常上，供你事后查证。它只在两种场景下由 JVM 自动触发：一是 try-with-resources 中资源关闭失败，二是你在 finally 里手动调用 addSuppressed()。关键区别在于：前者全自动、安全；后者要自己兜底，一不小心就写成遮蔽（shadowing）。
try-with-resources 怎么自动处理多个关闭异常
当你在 try(ResourceA a = new A(); ResourceB b = new B()) 中声明多个实现了 AutoCloseable 的资源，且 try 块本身抛出异常（比如 NullPointerException），而 a.close() 和 b.close() 又各自抛出 IOException，JVM 会：
- 以
try块的异常为最终抛出对象（主异常） - 将两个
close()异常分别调用mainException.addSuppressed(closeException) - 打印堆栈时，在主异常末尾显示
Suppressed: java.io.IOException...
你不需要写任何额外逻辑，getSuppressed() 就能拿到全部被抑制的异常。注意：Closeable 是 AutoCloseable 的子接口，老库里的 InputStream、Connection 都兼容。
手写 finally 时为什么不能 throw —— 遮蔽和抑制根本不是一回事
finally 里直接 throw 会导致原始异常彻底消失：JVM 不做任何附加，直接替换整个异常对象，栈追踪里连痕迹都没有。这不是“抑制”，是硬覆盖。常见踩坑点：
立即学习“Java免费学习笔记（深入）”；
- 写
resource.close()前没判空，NullPointerException吃掉上游的SQLException - 在
catch里记录日志后又throw e，接着finally里再throw new RuntimeException()，结果只看到后者 - 以为
catch里保存异常对象、finally里addSuppressed()再throw就万事大吉——但一旦finally抛异常，前面所有操作都白做
正确做法只有一条：在 finally 里所有可能失败的操作（如 close()）必须用独立 try-catch 包住，且 catch 块里只记录日志或忽略，绝不可 throw。
什么时候必须手动 addSuppressed()？
极少。只在你明确放弃 try-with-resources、又想保留异常上下文时才需要。例如封装一个工具方法，内部手动管理资源并希望暴露完整失败链：
Exception origin = null;
try {
doWork();
} catch (Exception e) {
origin = e;
} finally {
try {
cleanup();
} catch (Exception e) {
if (origin != null) {
e.addSuppressed(origin);
}
throw e;
}
}
但这种写法风险高：如果 cleanup() 没抛异常，origin 就丢了；如果 cleanup() 抛了，你得确保它真能拿到 origin。绝大多数情况下，老老实实用 try-with-resources 更省心也更可靠。
最容易被忽略的一点：suppressed 异常不会自动打日志，也不会触发监控告警——除非你显式遍历 getSuppressed() 并记录。线上出问题时，只看主异常堆栈，很可能漏掉真正致命的关闭失败。
