Suppressed异常是try-with-resources中关闭资源时被附加到主异常上的次要异常，由JVM自动调用addSuppressed()添加，按资源逆序关闭顺序依次压制，需通过getSuppressed()显式获取。
Suppressed 异常是什么，为什么它只在 try-with-resources 里冒出来
Suppressed 异常不是新抛出的异常，而是被“压住”没直接抛出来的关闭异常。它只在 try-with-resources 中出现，因为 JVM 在资源自动关闭阶段如果遇到多个异常（比如 try 块里已抛出一个 IOException，随后第一个资源的 close() 又抛出另一个 IOException），JVM 会把后者作为 suppressed 异常附加到主异常上，而不是覆盖或丢弃。
这和传统 finally 块完全不同：传统写法中，finally 里的异常会直接覆盖 try 块的异常，原始错误信息就丢了；而 try-with-resources 用 addSuppressed() 显式保留了上下文。
关键点：
-
Suppressed异常只能通过Throwable.getSuppressed()获取，printStackTrace()默认会打印它们（带Suppressed:前缀） - 只有关闭阶段（
close()调用）抛出的异常才可能被 suppressed；try块内抛出的异常永远是主异常 - suppressed 异常的顺序是「后关闭的资源先被 suppressed」——因为关闭按声明逆序执行，最后关闭的资源出错时，主异常已经存在，它的异常就被 suppress
多资源场景下 suppressed 异常的真实触发路径
假设有两个资源：FileInputStream fis 和 FileOutputStream fos，按此顺序声明：
立即学习“Java免费学习笔记（深入）”；
try (FileInputStream fis = new FileInputStream("in.txt");
FileOutputStream fos = new FileOutputStream("out.txt")) {
// 这里读写过程中抛出 IOException → 成为主异常
throw new IOException("read failed");
} catch (IOException e) {
// e 是主异常；若 fos.close() 或 fis.close() 报错，会被 suppress
}
关闭顺序是：先 fos.close()，再 fis.close()。所以：
- 如果
fos.close()抛异常，它会成为第一个 suppressed 异常 - 如果
fis.close()也抛异常，它会成为第二个 suppressed 异常（因为此时主异常已存在） - 但如果
try块没抛异常，而fos.close()抛了，那它就是主异常，fis.close()的异常才会被 suppress
也就是说：**谁先关、谁后错，谁更可能被 suppress —— 不是由你写的顺序决定，而是由关闭逆序 + 异常发生时机共同决定。**
怎么安全地检查和处理 suppressed 异常
不能只看 e.getMessage() 或默认日志输出，那会漏掉关键线索。必须显式遍历 getSuppressed()：
catch (IOException e) {
System.err.println("主异常: " + e.getMessage());
for (Throwable suppressed : e.getSuppressed()) {
System.err.println("Suppressed: " + suppressed.getMessage());
// 可选：记录完整堆栈，尤其当 suppressed 是 NullPointerException 等运行时异常时
suppressed.printStackTrace(System.err);
}
}
常见疏忽点：
- 日志框架（如 Log4j、SLF4J）默认不展开 suppressed 异常，需配置
%ex{full}或手动调用getSuppressed() - 测试时用
assertThrows只能捕获主异常，要验证 suppressed 必须用assertThat(e.getSuppressed()).hasSize(1)这类断言 - 如果 suppressed 异常是
NullPointerException，往往说明资源对象本身为null（比如构造失败后又尝试 close），这比 IO 错误更值得优先排查
suppress 不是兜底方案，它暴露的是设计缺陷
频繁看到 suppressed 异常，通常意味着资源生命周期管理出了问题：
- 资源在
close()阶段还依赖外部状态（比如网络连接已断，但流对象未置为无效） - 自定义
AutoCloseable实现里，close()方法没做空值/状态校验，直接操作底层句柄 - 多个资源存在隐式依赖（如
BufferedWriter包裹FileOutputStream），但关闭顺序没对齐，导致外层 close 时内层已失效
真正健壮的做法，是让每个 close() 调用幂等且不抛异常（或只抛 RuntimeException），而不是依赖 suppressed 机制来“收集错误”。否则，你不是在处理异常，是在归档故障现场。
