默认情况下 Throwable.printStackTrace() 不打印被抑制异常，只显示主异常；需调用 getSuppressed() 或使用支持抑制的打印方式才能查看完整链路。
try-with-resources 里抛异常，为啥看不到被抑制的异常？
因为默认情况下，Throwable.printStackTrace() 不会打印被抑制的异常，只显示主异常。想看到完整链路，得主动调用 getSuppressed() 或用支持抑制异常的打印方式（比如 printStackTrace() 在 Java 7+ 的标准输出中其实会显示，但 IDE 控制台或某些日志框架可能截断）。
- 真实场景：资源关闭时抛
IOException，而 try 块里已抛NullPointerException，后者是主异常，前者被抑制 - 常见错误：只捕获并打印
e，却没检查e.getSuppressed()，误以为关闭过程“没出错” - 注意：只有通过
addSuppressed()显式添加，或由 try-with-resources 自动添加的异常才会出现在getSuppressed()数组里
哪些异常会被 try-with-resources 自动抑制？
仅当 try 块已抛出异常（主异常），且资源的 close() 方法再抛异常时，后者才会被抑制。如果 try 块没抛异常，close() 抛的异常就是主异常，不会被抑制。
- 触发条件必须同时满足：
try块非正常退出 +close()抛异常 -
AutoCloseable.close()方法本身不能声明抛受检异常（否则编译不通过），但可以抛运行时异常（如RuntimeException）或未声明的受检异常（通过反射等绕过检查，不推荐） - 多个资源按逆序关闭：
res2.close()先于res1.close()调用；若都抛异常，后抛的会被加到先抛异常的抑制列表中
手动调用 addSuppressed() 的典型误用
直接对一个刚 new 出来的 Exception 调用 addSuppressed() 没有意义——它还没被抛出，JVM 不会自动关联栈信息，打印时也容易漏掉上下文。
- 正确做法：在 catch 块中，对捕获到的主异常调用
addSuppressed()，传入另一个已发生的异常实例 - 风险点：如果两个异常是同一实例（比如重复添加），
getSuppressed()会返回空数组（JVM 内部去重） - 性能影响：每个被抑制异常都会保留完整栈轨迹，大量抑制会增加内存开销，不适合循环中累积添加
Android 或低版本 JVM 上 suppress 机制不可用？
不是“不可用”，而是行为不同：getSuppressed() 和 addSuppressed() 在 Java 7 引入，Android API 19+（KitKat）才开始支持；低于此版本调用会抛 NoSuchMethodError。Java 6 及更早则根本不存在这些方法。
立即学习“Java免费学习笔记（深入）”；
- 兼容写法：用反射检测方法是否存在，再决定是否调用；或者统一用传统 finally + 多层 try/catch 捕获关闭异常
- 构建时注意：即使源码用了
addSuppressed()，若targetCompatibility = 1.6，编译会失败 - Logcat 或旧版 Timber 日志库默认不展开抑制异常，需手动遍历打印，否则调试时完全看不见
addSuppressed() 的那一刻捕获的，不是在原始异常发生时**。这意味着，如果关闭逻辑延迟执行（比如扔进线程池），那个栈可能指向线程调度点，而不是真实的资源操作位置。 
