addSuppressed() 是将次要异常附着到主异常以防止丢失的机制，而非异常处理器；真正处理需显式调用 getSuppressed() 遍历并记录日志或打印堆栈。
Java 的 addSuppressed() 不是“处理”异常的处理器，而是把次要异常**附着到主异常上**，确保它不被丢弃。真正“处理”被压制异常，靠的是后续显式调用 getSuppressed() 并做日志、告警或诊断——否则它们就像隐身了一样，控制台里根本看不到。
什么时候该用 addSuppressed()
只在以下情况手动调用：
- 主逻辑已失败（比如解析 JSON 报错、数据库写入失败），你捕获了这个异常（称为主异常）
- 紧接着在清理阶段（如关闭流、删除临时文件、释放锁）又发生了另一个独立异常
- 你希望保留这个清理异常的上下文，又不想让它覆盖主异常
典型位置是 finally 块中：先尝试清理，捕获其异常，再检查主异常是否存在，存在则调用 mainEx.addSuppressed(cleanupEx)。
怎么安全调用 addSuppressed()
必须避开几个常见坑：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 主异常对象不能为
null，否则抛NullPointerException - 不能把同一个异常对象重复添加，也不能加自己（
e.addSuppressed(e)），否则抛IllegalArgumentException - 必须在主异常
throw之前调用；一旦抛出，再调用就无效（不报错，但没效果） - 被压制异常本身也不能为空引用
示例片段：
ParseException mainEx = null;try { parse(input); }
catch (ParseException e) { mainEx = e; }
finally {
try { input.close(); }
catch (IOException closeEx) {
if (mainEx != null) mainEx.addSuppressed(closeEx);
}
}
if (mainEx != null) throw mainEx;
怎么真正“处理”被压制的异常
addSuppressed() 只负责存，不负责显。要让被压制异常发挥作用，必须主动拉出来：
- 调用
e.getSuppressed()获取Throwable[]数组（长度可能为 0） - 遍历数组，对每个被抑制异常调用
printStackTrace()或记录到日志中 - 在自定义日志框架（如 SLF4J + Logback）中，需显式循环打印，否则默认日志里不显示 suppressed 部分
- IDE（如 IntelliJ）调试时会自动折叠显示 “Suppressed: …”，点开即可查看，适合快速定位
别把被抑制异常当主因——它只是“善后失败”，排查优先级永远低于主异常。
和 try-with-resources 的关系
try-with-resources 是 addSuppressed() 的自动应用场：只要 try 块抛异常，且任一资源 close() 也抛异常，JVM 就自动把后者压制到前者上。但要注意：
- 多个资源关闭都失败时，JVM 只自动压制第一个
close()异常，其余可能被忽略 - 若你想确保所有关闭异常都不丢，就得手动管理：逐个
close()并捕获、全部addSuppressed() -
getSuppressed().length == 0不代表关闭成功——可能只是 try 块没抛异常，此时close()异常会直接作为主异常抛出
