现代Java框架将Checked异常包装为Unchecked异常并非退步，而是为解决分层污染、异常滥用和维护成本高问题：避免业务层暴露底层技术细节，消除无意义throws声明，防止空catch反模式，并通过@ControllerAdvice等机制实现集中化容错治理。
现代 Java 框架（如 Spring、Hibernate）普遍将原本的 Checked Exception（如 SQLException、IOException）包装为 Unchecked Exception（如 DataAccessException、RuntimeException 子类），这不是技术退步，而是对分层架构、API 可用性与错误治理逻辑的重新校准。
破坏分层封装：底层技术细节不该暴露给业务层
Checked Exception 要求调用链上每一层都声明或处理异常，导致业务方法被迫感知数据库或 I/O 实现细节：
-
public User getUser(Long id) throws SQLException—— 业务接口直接泄露了 JDBC 实现 - 上层服务若不关心“为什么查不到”，只关心“查不到怎么办”，却仍要写
throws SQLException，违背单一职责和抽象原则 - 一旦底层从 JDBC 切换到 JPA 或 NoSQL，所有签名和异常处理逻辑都要重写
异常污染调用链：强制传播带来大量无意义 throws
为满足编译要求，中间层常沦为“异常搬运工”，既不处理也不理解异常语义：
- Service 层方法本不涉及文件操作，却因调用了某个工具类而被迫声明
throws IOException - Controller 层最终 catch 住
IOException，但实际无法重试或修复——只能记录日志后转抛，徒增冗余代码 - 这种“为了编译而 throws”的写法稀释了真正需要关注的异常信号
掩盖真实问题：空 catch 和 printStackTrace 成为默认解法
当开发者面对大量必须处理的 Checked Exception，又缺乏清晰恢复策略时，容易走向反模式：
-
try { ... } catch (IOException e) { e.printStackTrace(); }—— 控制台输出掩盖了异常上下文，不利于监控告警 -
try { ... } catch (Exception e) { /* ignore */ }—— 异常被静默吞没，故障排查成本陡增 - 这类做法比不声明异常更危险：它制造了“已处理”的假象，实则放弃责任
转向集中化容错：用 Unchecked + 全局处理器替代分散式防御
框架选择 Unchecked 并非放弃错误处理，而是把控制权交给更高层次的统一机制：
- Spring 的
@ControllerAdvice可以按异常类型定义响应格式（如 400/500 状态码、JSON 错误体） - 业务代码专注核心逻辑，异常分类、日志脱敏、降级策略、告警触发全部收口在一处
- 配合自定义业务异常（如
UserNotFoundException），既能保持语义清晰，又避免编译器强制干扰
