java中受检异常处理的关键在于上下文传播、状态恢复与传播边界的精准把控：需通过异常链保留原始堆栈，区分可恢复（如网络抖动）与不可恢复场景（如sql语法错），在dao层不吞异常、service层决策策略、controller层统一转化，并确保资源操作与事务状态同步。
Java中受检异常的处理不只是“加个try-catch”那么简单，关键在于如何让异常携带的上下文信息真正服务于后续的状态判断与恢复决策。它不是被动拦截错误，而是主动管理执行流的中断点和重启点。
上下文传播：异常链不是装饰，是诊断主线
受检异常（如IOException、SQLException）天生支持异常链机制。当底层操作失败时，不应简单抛出新异常覆盖原始原因，而应用initCause()或构造函数中的cause参数保留原始异常：
- 避免丢失堆栈：原始异常的
stackTrace和detailMessage是定位IO超时还是数据库连接池耗尽的关键依据 - 分层包装有逻辑：Service层可将SQLException包装为DataAccessException，但必须设cause，否则DAO层的SQL语句、参数、驱动版本等上下文就断了
- 日志中打印
e.getCause()比只打e.toString()多出70%的有效排查线索
状态恢复：不能只靠“重试”，要区分可恢复与不可恢复场景
受检异常是否可恢复，取决于它所反映的系统状态是否具备重建条件：
- 可恢复典型场景：网络临时抖动导致的ConnectException，此时连接池未损坏，只需等待后重连；文件被其他进程短暂占用引发的FileNotFoundException，稍后可能释放
- 不可恢复典型场景：配置文件路径硬编码错误导致的FileNotFoundException，或SQL语法错误引发的SQLException——这类问题不改代码永远重试失败
- 恢复动作需配套状态清理：比如事务性操作中捕获SQLException后，若已开启事务但未提交，必须显式rollback，否则连接会卡在dirty状态
传播边界：在哪里截断，决定了恢复粒度
受检异常必须被显式处理，但“处理”的位置决定系统健壮性：
- DAO层不吞异常：不要在JDBC操作里catch SQLException后return null，这会让上层误判为“查无结果”而非“查失败”
- Service层做策略决策：捕获IOException后，可基于重试次数、错误码（如HTTP 503 vs 404）、业务SLA决定是降级返回缓存、切换备用数据源，还是抛出业务异常终止流程
- Controller层兜底转化：统一将未被捕获的受检异常转为标准响应体（如{code:500, message:"系统繁忙，请稍后再试"}），绝不暴露堆栈给前端
资源与状态同步：try-with-resources只是起点
受检异常常伴随资源操作，但自动关闭不等于状态一致：
- FileInputStream关闭成功 ≠ 文件写入完成：若write()抛出IOException，close()可能掩盖该异常（因suppressedExceptions机制），需在finally前检查业务状态
- 数据库连接归还连接池 ≠ 事务结束：Connection.close()不等于commit，必须确保事务管理器已明确结束事务生命周期
- 自定义资源类需重写
addSuppressed()逻辑：当主异常和清理异常并存时，明确哪个是根因，避免调试时被次要异常干扰
