在spring aop中，使用@around通知可统一管理方法前后的上下文（如事务、日志），但若希望异常穿透到调用方、同时确保“清理逻辑”（如资源释放、状态重置）始终执行，只需将核心逻辑包裹在try-finally块中，而非try-catch捕获并吞掉异常。
在spring aop中，使用@around通知可统一管理方法前后的上下文（如事务、日志），但若希望异常穿透到调用方、同时确保“清理逻辑”（如资源释放、状态重置）始终执行，只需将核心逻辑包裹在try-finally块中，而非try-catch捕获并吞掉异常。
@Around 是 Spring AOP 中功能最强大的通知类型，它完全控制目标方法的执行流程：你可以决定是否执行、何时执行、如何处理返回值或异常。但正因如此，错误地使用 catch 块会无意中“吞掉”原始异常，破坏正常的异常传播链——这在事务管理、权限校验或上下文清理等场景中尤为危险。
✅ 正确做法是：用 try-finally 保障后置逻辑执行，同时让异常原样向上抛出。如下示例展示了标准模式：
@Aspect
public class ContextCleanupAspect {
@Around("execution(* com.example.service..*(..))")
public Object manageContext(ProceedingJoinPoint joinPoint) throws Throwable {
// ✅ 前置：设置上下文（如开启数据库事务、绑定线程变量）
System.out.println("→ Setting up context for: " + joinPoint.getSignature());
try {
// ✅ 执行目标方法 —— 异常将直接穿透此处
Object result = joinPoint.proceed();
// 可选：对正常返回结果做轻量处理（如脱敏、缓存）
System.out.println("✓ Method succeeded: " + joinPoint.getSignature());
return result;
} finally {
// ✅ 必执行：清理逻辑（如提交/回滚事务、清除ThreadLocal、关闭连接）
System.out.println("← Cleaning up context for: " + joinPoint.getSignature());
cleanupContext(); // 实际业务中的清理方法
}
}
private void cleanupContext() {
// 示例：清空当前线程的数据库事务上下文或用户认证信息
TransactionSynchronizationManager.unbindResourceIfPossible(JDBC_CONNECTION_KEY);
ThreadLocalContext.clear();
}
}
⚠️ 注意事项：
- finally 块中禁止抛出新异常（或未处理的运行时异常），否则会覆盖原始异常，导致调试困难；
- 若需记录异常但不干预传播，应使用 @AfterThrowing 单独监听（更清晰、职责分离）；
- @Around 的 throws Throwable 声明必须保留，以兼容所有受检/非受检异常；
- 当无需修改参数、返回值，也无需在异常发生时做特殊响应时，组合使用 @Before + @AfterReturning + @AfterThrowing 更简洁、低侵入。
? 总结：@Around 完全支持“异常透传 + 清理必达”，关键在于避免 catch，善用 finally。它比拆分为多个通知更可控（尤其涉及共享状态时），且性能开销几乎无差异。选择 @Before/@After 组合仅当语义更清晰、逻辑完全解耦时才更优。
