受检异常应作为显式契约而非强制义务，仅用于外部可变因素导致的错误；业务逻辑错误宜用运行时异常；需在技术边界统一处理并转换为业务语义，避免中间层无效搬运。
受检异常本身不是问题，问题出在把它当成“必须层层捕获”的铁律。Java强制处理受检异常的本意是提醒开发者：某些错误（比如文件读取失败、数据库连接中断）是外部可变因素导致的，调用方理应知情并决策。但现实中，很多人把它变成了“流程负担”——每个方法都加throws，每层都套try-catch，最后业务逻辑被异常处理代码淹没，反而掩盖了真正该关注的错误路径。
把受检异常当“义务”，而不是“契约”
受检异常的本质是一种显式契约：它告诉调用方“这里可能发生这个具体问题，请你决定怎么应对”。但很多项目把它理解成“必须立刻处理”，结果在Service层捕获IOException后只记个日志再原样包装抛出，既没恢复也没降级，纯粹为了编译通过。这等于把契约执行成了形式主义。
- 真正需要处理的，是那些你能做点什么的场景：重试、降级、转换为用户友好的提示
- 如果上层根本无法干预（比如DAO层抛出的
SQLException，Service层既不重连也不补偿），那就统一向上声明，由最外层（如Controller或调度器）集中兜底 - 避免在中间层“接住又扔出”，这种“异常搬运工”模式既无业务价值，又污染堆栈
用运行时异常替代部分受检异常
不是所有可预见的失败都需要受检异常。比如参数校验失败、状态不满足前置条件、业务规则冲突——这些本质是编程逻辑问题，不是外部环境波动。用IllegalArgumentException或自定义RuntimeException更合适。
- 受检异常适合：I/O、网络、JDBC等底层资源交互类操作
- 运行时异常适合：输入非法、状态非法、业务约束违反等“不该发生但发生了”的情况
- 混用两者的关键是问一句：“这个错误，调用方有能力且有必要提前准备应对策略吗？”答案是否定的，就别用受检异常
统一异常转换，避免层层声明
一个典型反模式是：DAO抛SQLException → Service捕获后转成DaoException（受检）→ Controller再捕获转成ApiException（还是受检）。三层都得声明throws，最终却只返回HTTP 500。不如在框架入口处统一拦截原始受检异常，直接映射为清晰的业务错误码和消息。
- Spring中可用
@ControllerAdvice+@ExceptionHandler集中处理 - 自定义异常基类，区分“需用户感知”和“仅需日志记录”的类型
- 让受检异常止步于技术边界（如数据访问层），不出现在业务接口契约里
资源管理别靠手动try-catch
为关闭流或连接写一堆try-catch-finally，既是重复劳动，也容易漏掉close()或吞掉关闭异常。这不是受检异常的问题，而是没用对工具。
- 优先使用
try-with-resources，自动释放且编译器保证执行 - 如果资源类型不支持AutoCloseable，封装成工具方法，内部处理关闭逻辑和异常
- 不要在finally里再抛新异常，否则会覆盖原始异常；若关闭失败真要上报，应作为补充日志，而非替换主异常
