@AfterThrowing仅捕获方法正常执行后抛出的异常，若异常被try-catch吞没、发生在代理边界外（如线程池）、或目标方法非Spring Bean，则无法触发；需配合@Around实现异常兜底。
Java异常没被catch住，为什么AOP还是捕获不到？
因为 @AfterThrowing 切面只对「方法正常执行完但抛出异常」的场景生效，如果目标方法里自己 try-catch 了异常又没重新抛出，或者异常在 Spring 代理边界外（比如线程池、异步回调、静态方法）发生，AOP 就完全看不见。
常见错误现象：@AfterThrowing 一个日志都没打，但控制台明明有 NullPointerException 堆栈；或者只在 Controller 层生效，Service 里空指针却没触发切面。
- 确保目标方法是 Spring 管理的 Bean（不能 new 出来，也不能是 private/static）
- 检查是否开启了 AspectJ 代理模式：
@EnableAspectJAutoProxy(proxyTargetClass = true)更稳妥，尤其对接口多实现类的场景 - 若用
@Async或CompletableFuture，异常默认不传播到主线程，需显式处理或改用@Async的异常处理器
用 @AfterThrowing 拦截异常时，怎么拿到原始异常和参数？
靠切点表达式 + 方法签名匹配。Spring AOP 不支持直接获取被拦截方法的局部变量，但可以拿到入参、返回值（@AfterReturning）、异常对象（@AfterThrowing）和方法元信息。
使用场景：统一记录报错参数、脱敏手机号、标记重试标识、转发告警。
立即学习“Java免费学习笔记（深入）”；
@AfterThrowing(pointcut = "execution(* com.example.service..*.*(..))", throwing = "ex")
public void logException(JoinPoint joinPoint, Throwable ex) {
Object[] args = joinPoint.getArgs();
String methodName = joinPoint.getSignature().getName();
log.error("method={} args={} error={}", methodName, Arrays.toString(args), ex.getMessage());
}-
throwing = "ex"中的字符串必须和方法参数名严格一致 -
JoinPoint.getArgs()返回的是原始引用，修改它不影响原方法逻辑（但别真去改，语义混乱） - 如果只想拦截特定异常，切点里加
throws NullPointerException不起作用，得在方法体内if (ex instanceof XxxException)判断
Controller 层全局异常处理（@ControllerAdvice）和 AOP 切面冲突吗？
不冲突，但职责不同、触发时机不同。AOP 在方法执行后感知异常（属于「业务流程钩子」），而 @ControllerAdvice 是 Spring MVC 的异常翻译机制，在 DispatcherServlet 处理完 Controller 后才介入，且只对 Web 层有效。
性能影响：两者都轻量，但 @ControllerAdvice 会中断请求流程并渲染响应体，AOP 则纯属旁路记录/增强，不影响返回值。
- 想统一返回 JSON 错误结构 → 用
@ControllerAdvice + @ExceptionHandler - 想审计所有 service 方法的失败率、慢调用、入参特征 → 用 AOP
- 不要在
@ControllerAdvice里再 throw 新异常试图触发 AOP —— 此时方法早已执行完毕，AOP 不会二次响应
为什么切面里 try-catch 了异常，业务代码还是报错？
因为 @AfterThrowing 是「通知」，不是「拦截器」。它像站在门口看人摔跤，但不扶；你可以在里面记日志、发消息，但无法阻止异常向上冒泡。
真正能吞掉异常的只有 @Around，它把目标方法包在自己里面，有完全控制权。
@Around("execution(* com.example.service..*.*(..))")
public Object handleException(ProceedingJoinPoint joinPoint) throws Throwable {
try {
return joinPoint.proceed();
} catch (BusinessException e) {
log.warn("business error ignored: {}", e.getMessage());
return Result.fail(e.getCode(), "操作失败");
}
}-
@Around必须显式调用proceed()，否则目标方法根本不会执行 - 若
proceed()抛出异常，你 catch 之后可以选择返回默认值、包装新异常、或重新 throw - 过度使用
@Around容易掩盖真实问题，建议只在明确需要「兜底返回」的场景用（如降级、缓存穿透防护）
最容易被忽略的一点：AOP 和异常处理不是替代关系，而是分层协作。底层 Service 抛具体异常，中间 AOP 做可观测性增强，上层 Web 层做用户友好的错误呈现 —— 三层各干各的，混在一起反而难定位。
