try-with-resources中主异常是try块最先抛出的异常，close异常被压制并存入getSuppressed()数组；默认printStackTrace()不显示压制异常，需显式调用getSuppressed()获取，且压制异常最多存储64个。
try-with-resources 中的“异常压制”不是丢弃异常，而是把次要异常藏起来，优先抛出主异常。核心逻辑是：谁先出问题、谁更关键，谁就当主异常；后续关闭资源时再出的问题，就作为被压制的异常存进 getSuppressed() 数组里。
主异常和压制异常是怎么定的
主异常一定是 try 块里最先抛出的那个异常。只要 try 块执行中出了错，哪怕后面 close() 也失败了，那个 close 异常也不会取代它，只会被压制。
- 如果 try 块没抛异常，但某个 close() 失败了，那这个 close 异常就是主异常
- 如果 try 块抛了异常 A，而 close() 抛了异常 B，A 是主异常，B 进入
e.getSuppressed() - 多个资源时，close 按声明逆序执行，压制顺序也按这个来：后声明的资源先 close，它的异常排在
getSuppressed()数组前面
为什么默认看不到被压制的异常
printStackTrace() 只显示主异常和它的 cause 链，不自动展开 suppressed 部分。这是设计选择，避免堆栈信息过长干扰主线问题。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 必须显式调用
e.getSuppressed()才能拿到被压制的异常数组 - 数组长度可能是 0（没压制）、1（常见），或更多（多个 close 失败）
- 每个压制异常都是完整
Throwable对象，可以调用getMessage()、printStackTrace()等
压制机制有哪些实际限制
它不是万能兜底，有明确边界：
立即学习“Java免费学习笔记（深入）”；
- 只对实现
AutoCloseable的资源生效；如果 close() 抛的是Error（比如OutOfMemoryError），JVM 可能直接终止线程，压制逻辑不触发 - JDK 内部硬编码最多存 64 个压制异常，超出部分会被静默丢弃——线上偶发“异常信息变少”，可能就卡在这儿
- 压制异常是原异常的副本，修改它不影响原始异常对象
怎么在代码里安全处理压制异常
在 catch 块中别只打印主异常，多走一步检查压制项：
- 先判断
e.getSuppressed().length > 0 - 遍历数组，对每个压制异常做日志记录或进一步分析
- 例如：
for (Throwable s : e.getSuppressed()) { System.err.println("Suppressed: " + s.getMessage()); }
