RuntimeException在Spring、Hibernate等大型框架中，不是“可选配角”，而是事务控制、错误传播和设计契约的核心支点。
事务回滚的默认触发器
Spring事务管理器默认只对未捕获的RuntimeException（及其子类）和Error执行回滚。这意味着：
- 抛出NullPointerException、IllegalArgumentException或自定义的BusinessException extends RuntimeException，事务自动回滚；
- 抛出IOException、SQLException这类CheckedException，默认不回滚——除非显式配置
@Transactional(rollbackFor = SQLException.class)； - 如果在service方法里用try-catch吞掉RuntimeException，且没重新throw，事务不会回滚——因为AOP代理已收不到异常信号。
Hibernate操作天然倾向RuntimeException
Hibernate将底层JDBC异常（如SQL语法错、主键冲突）统一包装为PersistenceException及其子类（如ConstraintViolationException），它们全部继承自RuntimeException。这样设计的好处是：
- 避免DAO层被迫写满throws SQLException，让业务代码更干净；
- 强制开发者把数据一致性问题当作“逻辑缺陷”来修复（比如插入重复邮箱前应先查重），而不是靠catch兜底；
- 与Spring事务无缝协同——违反唯一约束直接抛ConstraintViolationException，事务立刻回滚。
框架级异常设计体现分层契约
Spring自身大量使用RuntimeException表达“调用方违规”或“配置错误”：
- BeanCreationException：Spring容器启动失败，说明配置或依赖有硬伤；
- IllegalStateException：某bean状态非法（如已关闭的连接再调close），属于调用时序错误；
- HttpRequestMethodNotSupportedException：Controller方法不支持当前HTTP方法，是路由配置问题。
这些都不是外部环境导致的偶然故障，而是程序逻辑或配置本身出了问题——框架选择RuntimeException，就是在告诉开发者：“这不是你该catch的场景，这是你该改代码的地方。”
全局异常处理的统一入口
Spring MVC的@ControllerAdvice和Spring Boot的ProblemDetail机制，主要面向RuntimeException构建响应策略：
- 参数校验失败（MethodArgumentNotValidException）→ 返回400；
- 空指针或类型转换失败（ConversionFailedException）→ 统一转为500并记录堆栈；
- 业务异常（如InsufficientBalanceException extends RuntimeException）→ 映射为403或自定义业务码。
而CheckedException通常被框架内部消化（如JDBC模板自动转换SQLException），或要求开发者在Service层主动声明并向上透传——它更适合作为需要明确恢复策略的“可预期故障”。
