全局异常处理器默认不捕获受检异常，因其在编译期必须显式处理；未声明的受检异常无法通过编译，根本不会进入运行时捕获流程；真正可被@ControllerAdvice拦截的是被包装成RuntimeException或Spring封装后的运行时异常。
全局异常处理器默认不捕获受检异常（Checked Exception）的“漏网之鱼”，因为这类异常在编译期就必须被显式处理——要么 try-catch，要么 throws 声明。如果某处本该处理却没处理（比如开发者疏忽、throws 被意外移除、或动态反射调用绕过编译检查），JVM 会直接拒绝加载或抛出 NoSuchMethodError 等错误，根本不会走到运行时异常捕获环节。所以严格来说，**受检异常不存在“运行时漏网”**；真正可能“漏掉”的，是那些本该被声明/捕获、却因代码变更或设计缺陷而未被处理的受检异常场景。
为什么@ControllerAdvice无法拦截未声明的受检异常
Spring 的 @ControllerAdvice + @ExceptionHandler 只作用于已进入 Spring MVC 执行链的异常，且仅对实际抛出的 Throwable 生效。但受检异常若未在方法签名中声明 throws，编译器会报错，代码根本无法编译通过——它连 JVM 都进不去，更不会触发任何运行时异常处理器。
换句话说：没有“漏网”的受检异常，只有“本不该出现却出现了”的非受检化行为，比如：
- 将受检异常包装成
RuntimeException后抛出（如throw new RuntimeException(e)） - 通过反射调用方法，绕过编译检查，导致受检异常以
InvocationTargetException形式包裹后抛出 - 使用函数式接口（如
Supplier）执行含受检异常的逻辑，而未做转换
真正需要兜底的“类受检异常”场景
实践中，以下几类情况看似像“受检异常漏网”，实则属于运行时异常范畴，可被全局处理器捕获：
-
JSR-303 参数校验失败：抛出
MethodArgumentNotValidException（继承自RuntimeException），必须靠@ControllerAdvice捕获 -
JSON 反序列化失败：Jackson 抛出
JsonProcessingException（虽是受检异常，但 Spring 默认将其包装为HttpMessageNotReadableException，属运行时异常） -
数据库访问异常：JDBC 的
SQLException在 Spring JDBC 或 JPA 中通常被转为DataAccessException子类（全部是 unchecked） -
手动包装的受检异常：如
throw new RuntimeException(new IOException("xxx"))，此时外层是运行时异常，可被捕获
如何增强对“伪装成运行时”的受检异常兜底
若业务中大量存在将受检异常转为运行时异常的习惯（例如统一用 BusinessException 包装），建议在全局处理器中显式捕获其根因：
- 在
@ExceptionHandler(RuntimeException.class)方法中，调用e.getCause()判断是否为原始受检异常（如IOException、SQLException） - 根据 cause 类型返回差异化错误码和提示，避免把底层 I/O 错误暴露为泛泛的“系统异常”
- 配合日志记录完整栈轨迹（包括 cause），便于定位真实问题源头
编译期防御才是根本
要杜绝受检异常被忽略，不能只依赖运行时兜底。应从工程规范入手：
- 启用 IDE 和构建工具（如 Maven Checkstyle / ErrorProne）强制检查未处理的受检异常
- 约定所有 DAO 层方法统一抛出自定义受检异常（如
DataAccessException），并在 Service 层明确throws或转换 - 禁止无理由的
catch (Exception e) { throw new RuntimeException(e); }—— 这等于主动放弃编译期保护
全局异常处理器的价值在于统一响应格式、记录日志、避免崩溃，而非替代编译检查。对受检异常，信任编译器比依赖运行时更可靠。
