非受检异常提升接口稳定性与可维护性：避免签名频繁变更、减少无意义包装、增强可读性、支持分层解耦。
非受检异常（RuntimeException及其子类）不强制在方法签名中声明 throws，最直接的好处是让接口更干净、更稳定、更易演进。
避免方法签名频繁变动
受检异常一旦抛出，所有调用链上的方法都必须显式声明 throws，哪怕只是透传。新增一个校验逻辑（比如 DAO 层加了个空值检查并抛 SQLException），就得一路改 Service、Manager、Controller 的方法签名——这破坏接口契约，也违背开闭原则。
- 非受检异常可随时抛出，无需修改任何上层方法签名
- 团队协作时，接口定义更“耐改”，版本兼容性压力小
- 重构校验逻辑、切换底层实现（如换数据库驱动）不再牵一发而动全身
减少无意义的异常包装和透传
为满足编译要求，开发者常把受检异常层层包装成业务异常：new ServiceException(new DaoException(e))。结果堆栈冗长、原始错误被掩盖、语义模糊。
- 非受检异常直抛，调用链保持扁平，异常源头清晰可见
- 配合自定义业务异常（如
UserException.userNotFound()），错误意图一目了然 - 全局异常处理器（如
@ControllerAdvice）统一收口，响应格式、日志、监控集中管控
提升接口可读性与聚焦业务
方法签名里塞一堆 throws IOException, SQLException, TimeoutException，实际使用者很难分辨哪些是真正需要关注的业务约束，哪些只是技术细节噪音。
- 签名只保留核心参数和返回值，阅读成本低
- 开发者注意力自然集中在“这个方法做什么”，而非“它可能被什么打断”
- 业务异常语义化后（如
InsufficientBalanceException），接口本身就是文档
支持微服务分层解耦设计
微服务内部各层（DAO/Service/API）本就不该为技术异常暴露实现细节。网关或 Controller 层才是统一响应策略的边界。
- DAO 层抛
DbConnectionException？没必要——它应转为SystemException并由网关兜底 - Service 层只关心“用户不存在”“库存不足”等业务事实，不操心底层是 JDBC 还是 MongoDB
- 非受检异常天然适配这种“边界收敛”架构，无需每层重复声明和翻译
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
