受检异常是编译期契约机制，非控制流工具；应通过分层异常处理、语义化包装（如将SQLException转为DataAccessException）和统一异常处理器（如@ControllerAdvice）实现精准响应，避免在业务逻辑中用多层catch做分支。
受检异常本身不能“精准分支捕获”——它不是控制流工具，而是编译期契约机制。真正能精简冗长重叠旧代码的，是**结合受检异常语义 + 分层异常统一处理 + 语义化异常包装**的一套实践组合，而非靠多层 try-catch 做条件分支。
明确受检异常的定位：契约，不是开关
IOException、SQLException 等受检异常表达的是“外部可恢复故障”，不是业务状态分支（如“用户不存在”或“余额不足”）。强行用它们做逻辑分路，比如：
❌ 错误示范（混淆职责）：try {
readFile(); // 抛 IOException
} catch (FileNotFoundException e) {
// 当作“用户未上传文件”处理
redirect("/upload");
} catch (SecurityException e) {
// 当作“权限不足”跳转
redirect("/forbidden");
}
这会让异常类型承担业务路由职责，破坏分层抽象，也违背受检异常的设计本意。
用统一异常处理器替代重复 catch 块
旧代码中常见每个 service 方法都写一模一样的 try-catch-log-throw-response 模板。解法是上收至框架层：
- Spring 项目：用 @ControllerAdvice + @ExceptionHandler 拦截特定受检异常，转换为统一错误响应
- 非 Spring 项目：在 Servlet Filter 或统一网关处捕获 Throwable，对 instanceof SQLException / IOException 做归类处理
- 关键点：只在入口层（如 Controller）让受检异常“透出”，中间 service 层不主动捕获，也不 throws 向上传播细节异常（如不写 throws SQLException）
包装为语义化业务异常，切断底层泄漏
数据访问层抛出 SQLException 是合理的；但服务层签名写 throws SQLException 就错了。应立即包装：
✅ 正确做法：
public Order getOrder(Long id) {
try {
return orderMapper.selectById(id);
} catch (SQLException e) {
throw new DataAccessException("查询订单失败", e);
}
}
这样上层只需关注 DataAccessException 及其子类（如 OrderNotFoundException），不再感知数据库实现。后续可基于这些业务异常做精准响应，而不是对着 IOException 写一堆 if-else。
配合现代语法进一步消减样板
Java 16+ 可结合模式匹配简化异常处理中的类型判断（虽不直接用于受检异常，但在统一处理器中很有用）：
if (e instanceof DataAccessException dae) {
if (dae.getCause() instanceof SQLTimeoutException) {
return buildRetryResponse();
}
}
比起传统 instanceof + 强转，更安全简洁；配合自定义异常分类，就能实现“精准”响应，而无需在每个业务方法里堆砌重复逻辑。
