try-with-resources会压制原始异常是因为其设计原则是主异常优先：try块抛出的异常为主异常，close()异常被抑制并存入getsuppressed()数组；必须显式调用getsuppressed()才能获取被压制的异常，否则默认printstacktrace()仅显示主异常。
为什么 try-with-resources 会吞掉原始异常
当 try 块抛出异常，且后续资源 close() 又抛出异常时，try-with-resources 默认只把 close 异常作为主异常抛出，而把 try 块里的原始异常“压制”（suppressed）——不是丢弃，而是藏进 getSuppressed() 列表里。这导致你只看到一个异常堆栈，误以为问题出在 close 阶段，实际根源可能在业务逻辑里。
如何可靠获取被压制的异常
必须显式调用 getSuppressed()，不能只看 printStackTrace() 的默认输出。它返回 Throwable[]，长度可能为 0（无压制）、1（常见）或更多（多资源依次 close 失败）。
- 在 catch 块中，先检查
e.getSuppressed().length > 0 - 遍历
e.getSuppressed()，对每个压制异常调用printStackTrace()或提取关键信息（如e.getSuppressed()[0].getMessage()） - 注意：
getSuppressed()返回的是副本，修改它不影响原异常
多资源场景下压制异常的顺序怎么理解
资源关闭按声明逆序执行，压制异常的添加顺序也按此规则：后声明的资源先 close，若失败，其异常成为第一个被压制的；先声明的资源后 close，其异常排在后面。例如：
try (FileInputStream fis = new FileInputStream("a.txt");
FileOutputStream fos = new FileOutputStream("b.txt")) {
// ... 抛出 IOException
}
若 fis.close() 和 fos.close() 都失败，fos.close() 的异常会先被压制（索引 0），fis.close() 的异常排在索引 1。
suppress 机制本身有哪些限制
addSuppressed() 不是万能的。它只对实现了 AutoCloseable 的资源生效；如果某个 close 方法抛出的是 Error（比如 OutOfMemoryError），JVM 可能直接终止线程，压制逻辑不会触发。另外，压制异常最多存储 64 个（JDK 内部硬编码限制），超出部分会被静默丢弃——这点极难察觉，但线上偶发的“异常信息变少”可能就源于此。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
