Spring 的 @ControllerAdvice + @ExceptionHandler 机制在语义上借鉴了 AOP 的“通知（advice）”概念，但底层并非通过 Spring AOP 的代理机制（如 @Around 或 @AfterThrowing）实现，而是由 Spring MVC 框架在 DispatcherServlet 执行链中主动触发的原生调度逻辑。
spring 的 `@controlleradvice` + `@exceptionhandler` 机制在语义上借鉴了 aop 的“通知（advice）”概念，但底层并非通过 spring aop 的代理机制（如 `@around` 或 `@afterthrowing`）实现，而是由 spring mvc 框架在 `dispatcherservlet` 执行链中主动触发的原生调度逻辑。
Spring 全局异常处理本质上是 Spring MVC 的核心调度能力，而非 Spring AOP 的代理增强结果。虽然 @ControllerAdvice 中的 “advice” 一词明显呼应 AOP 术语，且其设计思想（横切关注点、统一处理异常）与 AOP 高度一致，但其实现路径截然不同：
- ✅ 无代理介入：被
@Controller或@RestController标注的控制器类，即使注册了全局异常处理器，也不会因此被 Spring AOP 创建 JDK 动态代理或 CGLIB 代理；查看 Bean 的实际类型（如通过AopUtils.isAopProxy(bean)）可验证其非代理对象。 - ✅ 框架内建调度：异常捕获发生在
DispatcherServlet.doDispatch()的核心执行流程中。当 HandlerMethod 执行抛出异常后，DispatcherServlet会委托HandlerExceptionResolver链进行解析——而ExceptionHandlerExceptionResolver（正是@ExceptionHandler的承载者）会根据预扫描缓存的mappedMethods（即你贴出的getMappedMethod方法所操作的 Map），按异常继承深度匹配最具体的处理方法，最终调用它完成响应。
以下为关键行为佐证：
// DispatcherServlet.java（简化示意）
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
try {
// ... 执行 handler（即 Controller 方法）
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
} catch (Exception ex) {
// 异常发生 → 进入异常解析流程
dispatchException = ex;
}
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
private void processDispatchResult(...) {
if (dispatchException != null) {
// 触发 HandlerExceptionResolver 链
ModelAndView mv = handlerExceptionResolver.resolveException(request, response, handler, dispatchException);
// ...
}
}⚠️ 注意事项：
-
@ControllerAdvice类在应用启动时即被ExceptionHandlerExceptionResolver扫描并缓存其@ExceptionHandler方法映射关系（即mappedMethods），该过程独立于 AOP 的AspectJAdvisorFactory或AdvisedSupport。 - 若需真正基于 AOP 的异常拦截（例如对任意 Service 方法做统一异常日志/重试），应显式使用
@Aspect+@AfterThrowing，而非依赖 MVC 异常机制。 -
@Transactional等注解才属于典型的 Spring AOP 应用：它们会触发代理创建，并在代理方法前后织入增强逻辑。
✅ 总结：
全局异常处理是 Spring MVC 的原生横切机制，它复用了 AOP 的设计哲学（分离关注点），但选择了更轻量、更可控的框架内调度方案，而非引入代理开销。因此，它“是 AOP 思想的体现”，但“不是 Spring AOP 技术的实现”。理解这一区别，有助于准确定位问题（如为何断点进不了 @Around）、合理选择技术方案（MVC 异常 vs. 自定义 AOP 切面），并避免对 Spring 内部机制产生误判。
