Spring AOP从入门到避坑：核心概念、动态代理与实战场景全解析

1. 为什么AOP是Spring里最值得先啃透的一块硬骨头

刚接触Spring那会儿，我最先学会的是IoC，把对象交给容器管，用的时候@Autowired一注就完事，确实省心。但真正让我觉得Spring“有点东西”的，是AOP。原因很简单：IoC解决的是对象怎么来的问题，而AOP解决的是“一堆方法里重复横切的逻辑怎么抽出去”的问题。日志、事务、权限校验、接口耗时统计、缓存、限流，这些代码如果每个方法都手写一遍，项目很快就会变成一锅粥。AOP就是把这些“跟业务无关但每个业务都要沾一点”的逻辑，从业务代码里剥出来，统一织进去。

这篇内容我打算把Spring中AOP的基本使用从头到尾捋一遍。不是那种只贴两行@Aspect就结束的教程，而是把“为什么这么设计”“注解背后发生了什么”“实际项目里怎么用才不出事”讲清楚。适合已经会写Spring基础代码、能跑起来一个Spring Boot项目、但对AOP还停留在“听说过、抄过、没真正理解”阶段的同学。看完之后，你应该能独立写出可用的切面，知道什么时候该用AOP、什么时候不该用，以及踩坑时往哪个方向排查。

先说清楚AOP到底是个啥。AOP全称Aspect Oriented Programming，面向切面编程。你可以把它理解成给方法“套壳”：原本你调用的是userService.save()，AOP可以在不修改save()源码的前提下，在它执行前、执行后、抛异常时、甚至环绕整个执行过程插入额外逻辑。这个“壳”就是切面，插入的位置叫连接点，插入的时机叫通知。Spring AOP底层用的是动态代理，这点非常关键，后面会展开讲，因为它直接决定了哪些方法能被增强、哪些不能。

我见过太多人AOP用不明白，根子都在没搞懂代理机制。比如为什么private方法加了注解不生效？为什么同一个类里this.xxx()调用不走切面？为什么final方法切不到？这些问题不是配置写错了，而是动态代理的天然限制。所以这篇我会把原理和实操绑在一起讲，让你不光会抄，还能自己判断。

2. AOP核心概念一次讲透，别再被术语绕晕

2.1 五个核心术语，用生活场景类比

AOP的术语第一次看确实劝退，什么切点、连接点、通知、切面、织入，一堆名词。我用“公司门禁”这个场景给你类比一下，一下就通了。

• 连接点（JoinPoint）：程序执行过程中所有“可以被插入逻辑的点”。类比：公司里每一扇门，理论上都可以装门禁。
• 切点（Pointcut）：从所有连接点里，用规则筛选出“真正要插入逻辑的点”。类比：你规定“只有财务室和机房的门装门禁”，这个筛选规则就是切点。
• 通知（Advice）：在切点选中的位置上，具体要执行的逻辑，以及执行的时机。类比：门禁刷卡这个动作，以及是进门刷、出门刷、还是进出都刷。
• 切面（Aspect）：切点加通知的组合体，也就是“在哪、什么时候、干什么”的完整封装。类比：整套门禁方案。
• 织入（Weaving）：把切面逻辑真正塞进目标方法的过程。类比：施工队把门禁设备装到门上。

Spring AOP里的织入是运行期完成的，靠动态代理实现，不需要特殊的编译器。这点和AspectJ的编译期织入不一样，也是Spring AOP能力边界更窄的原因。

2.2 五种通知类型，时机决定用途

通知类型决定了你的逻辑在目标方法的哪个位置执行，选错了时机，逻辑就会出问题。下面这张表是我自己整理的高频对照，建议收藏。

这里有个特别容易搞混的点：@After和@AfterReturning的区别。@After相当于finally，不管方法正常返回还是抛异常都会执行；@AfterReturning只在正常返回时执行。很多人做资源清理用了@AfterReturning，结果方法一抛异常资源就泄漏了，这就是时机选错的典型后果。

2.3 切点表达式，写对了才切得准

切点表达式是AOP里最容易写错的部分。Spring AOP用的是AspectJ的切点表达式语法，最常用的就是execution。它的完整格式是：

execution(修饰符 返回类型 包名.类名.方法名(参数类型) throws 异常)

实际写的时候大部分可以省略，但省略的规则要清楚。举几个我项目里最常用的例子：

// 匹配 com.example.service 包下所有类的所有public方法 execution(* com.example.service.*.*(..)) // 匹配任意包下 Service 结尾的类的所有方法 execution(* com.example..*Service.*(..)) // 匹配指定注解标注的方法 @annotation(com.example.annotation.LogRecord) // 匹配指定注解标注的类里的所有方法 @within(com.example.annotation.LogRecord)

..表示任意层级包或任意参数，*表示任意返回值或任意方法名。我个人的经验是，切点表达式尽量写精确，不要图省事用execution(* *(..))这种全匹配，否则连框架内部方法都可能被切到，性能和安全都是隐患。

提示：切点表达式写完后，强烈建议先开DEBUG日志观察实际匹配了哪些方法，Spring会打印Applying pointcut相关的日志，确认无误再往下写通知逻辑。

3. 从零搭一个可运行的AOP示例

3.1 依赖引入与基础配置

Spring Boot项目里用AOP，只需要加一个starter，不需要额外配置类。这是Spring Boot最舒服的地方。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>

这个starter会自动引入aspectjweaver，并且通过AopAutoConfiguration自动开启@EnableAspectJAutoProxy。如果你用的是纯Spring（非Boot）项目，那就得手动在配置类上加@EnableAspectJAutoProxy，否则切面注解全部不生效。我早期踩过这个坑，注解写得漂漂亮亮，结果一个通知都不触发，排查半天才发现是没开自动代理。

关于@EnableAspectJAutoProxy还有两个参数值得说：

• proxyTargetClass：默认false，表示优先用JDK动态代理；设为true则强制用CGLIB。Spring Boot 2.x之后默认就是true了。
• exposeProxy：默认false，设为true后可以通过AopContext.currentProxy()拿到当前代理对象，用来解决自调用不走切面的问题。

3.2 第一个切面：接口耗时统计

我拿“接口耗时统计”作为第一个例子，因为它足够实用，而且能覆盖环绕通知的完整写法。

@Aspect @Component public class CostTimeAspect { private static final Logger log = LoggerFactory.getLogger(CostTimeAspect.class); @Around("@annotation(com.example.annotation.CostTime)") public Object around(ProceedingJoinPoint pjp) throws Throwable { long start = System.currentTimeMillis(); String method = pjp.getSignature().toShortString(); try { Object result = pjp.proceed(); return result; } finally { long cost = System.currentTimeMillis() - start; log.info("方法 {} 耗时 {} ms", method, cost); } } }

配套的自定义注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface CostTime { }

用的时候直接在方法上加@CostTime就行。这里有几个细节值得展开。

第一，pjp.proceed()必须调用，而且只能调用一次（除非你有意重试）。环绕通知里如果不调用proceed()，目标方法根本不会执行，这是新手最常见的错误之一。

第二，耗时统计放在finally里，保证方法抛异常时也能记录。如果放在proceed()后面直接写，异常一抛就跳过了。

第三，pjp.getSignature().toShortString()拿到的是“类名.方法名(参数类型)”的简写，比toString()干净，日志里更好看。

3.3 切点表达式的三种常用写法对比

实际项目里，切点定义方式主要有三种，各有适用场景，我做了个对比。

我个人的偏好是：能用注解匹配就用注解匹配。原因很实在——注解匹配是“显式声明”，谁被增强了、为什么被增强，看代码一目了然；包路径匹配是“隐式生效”，新人接手项目时经常一脸懵，不知道这个方法为什么突然多了日志。当然，像全局异常处理、统一日志这种确实需要批量生效的场景，包路径匹配更合适。

3.4 切面的执行顺序怎么控制

一个方法上如果挂了多个切面，执行顺序就成了问题。比如日志切面和事务切面，谁先谁后？Spring里控制顺序有两种方式：

• 实现Ordered接口，重写getOrder()方法
• 在切面类上加@Order(数字)注解

数字越小，优先级越高。对于环绕通知，优先级高的在外层，优先级低的在内层。也就是说@Order(1)的切面会先进入、后退出，像洋葱一样包住@Order(2)的切面。

@Aspect @Component @Order(1) public class LogAspect { } @Aspect @Component @Order(2) public class TransactionAspect { }

这里有个经验：事务切面的优先级要设得比较低（数字大），让它尽量贴近目标方法。因为事务的开启和提交应该紧贴业务逻辑，如果日志切面在事务外层，日志记录的时间点可能和事务边界对不上，排查问题时容易误判。

4. 动态代理机制：AOP能不能生效全看它

4.1 JDK动态代理与CGLIB的区别

Spring AOP的底层就两种代理方式，理解它们的差异，AOP的很多“玄学问题”就都有答案了。

JDK动态代理基于接口，要求目标类必须实现至少一个接口，生成的代理类和目标类实现同一接口。CGLIB基于继承，通过生成目标类的子类来实现代理，所以不能代理final类和final方法。

Spring Boot 2.x开始，spring.aop.proxy-target-class默认是true，也就是默认走CGLIB。这个默认值的变化，主要是为了解决“注入接口时拿不到实现类特有方法”的问题。但不管用哪种代理，private方法、static方法、final方法都无法被增强，这是硬性限制。

4.2 自调用失效问题与三种解法

自调用失效是AOP最经典的坑，没有之一。看这段代码：

@Service public class OrderService { public void createOrder() { // 这里调用本类的另一个方法 this.sendNotify(); } @CostTime public void sendNotify() { // 发送通知逻辑 } }

createOrder()里调用sendNotify()，@CostTime不会生效。原因是this指向的是原始对象，不是代理对象，方法调用根本没经过代理。这个问题有三种解法，我按推荐程度排序。

解法一：拆到另一个Bean里。把sendNotify()挪到独立的NotifyService里，通过注入调用。这是最干净的做法，符合单一职责，也避免了代理问题。我现在的项目基本都这么干。

解法二：注入自己。在OrderService里注入OrderService自身，用注入的实例调用方法。Spring能处理这种循环依赖（默认允许），但看起来有点怪。

@Service public class OrderService { @Autowired private OrderService self; public void createOrder() { self.sendNotify(); } }

解法三：开启exposeProxy，用AopContext.currentProxy()。需要在启动类或配置类上加@EnableAspectJAutoProxy(exposeProxy = true)，然后：

public void createOrder() { ((OrderService) AopContext.currentProxy()).sendNotify(); }

这种方式代码侵入性强，而且强转容易出错，我不太推荐。除非是老项目改造，实在没法拆Bean，才考虑它。

4.3 代理对象与原始对象的区分

有个细节很多人没注意：注入到其他Bean里的，永远是代理对象；而this永远是原始对象。你可以写个测试验证一下：

@Autowired private OrderService orderService; @Test public void testProxy() { System.out.println(orderService.getClass().getName()); // 输出类似 com.example.OrderService$$EnhancerBySpringCGLIB$$xxx }

看到$$EnhancerBySpringCGLIB$$或者$Proxy前缀，就说明拿到的是代理对象。这个技巧在排查“切面为什么不生效”时特别有用——先确认你调用的到底是不是代理。

注意：如果你在切面里用pjp.getTarget()，拿到的是原始对象；用pjp.getThis()，拿到的是代理对象。这两个方法在需要反射获取注解时经常用到，别搞混。

5. AOP在真实项目里的高频使用场景

5.1 统一日志记录

日志是AOP最普遍的应用。但我要提醒一句：不要无脑记录所有方法的入参和返回值。我见过一个项目，切面把每个方法的参数都JSON.toJSONString打出来，结果大对象序列化直接把接口响应时间拉高了几十毫秒，日志文件一天涨几个G。

合理的做法是：只对关键业务方法记录，并且对参数做长度截断。

@Around("@annotation(com.example.annotation.LogRecord)") public Object logAround(ProceedingJoinPoint pjp) throws Throwable { MethodSignature signature = (MethodSignature) pjp.getSignature(); Method method = signature.getMethod(); LogRecord annotation = method.getAnnotation(LogRecord.class); String desc = annotation.value(); Object[] args = pjp.getArgs(); String argsStr = truncate(Arrays.toString(args), 500); long start = System.currentTimeMillis(); try { Object result = pjp.proceed(); log.info("[{}] 入参={} 结果={} 耗时={}ms", desc, argsStr, truncate(String.valueOf(result), 500), System.currentTimeMillis() - start); return result; } catch (Throwable e) { log.error("[{}] 入参={} 异常={}", desc, argsStr, e.getMessage(), e); throw e; } }

truncate方法自己实现，超过长度就截断加省略号。这个细节看着小，但在生产环境里能救命。

5.2 声明式事务的AOP本质

@Transactional本质上就是一个AOP切面，这个认知很重要。理解了它，你就能明白为什么事务会失效。

事务失效的常见原因，几乎都能用AOP原理解释：

• 自调用：this调用不走代理，事务不生效。
• 方法非public：CGLIB虽然理论上能代理protected，但Spring的事务切面只对public方法生效。
• 异常类型不匹配：默认只对RuntimeException和Error回滚，受检异常不回滚，需要rollbackFor指定。
• 类没被Spring管理：new出来的对象没有代理，自然没有事务。

@Transactional(rollbackFor = Exception.class) public void transfer(Long from, Long to, BigDecimal amount) { // 扣款、入账逻辑 }

我个人的习惯是，@Transactional一律加上rollbackFor = Exception.class，避免受检异常不回滚的坑。这个习惯是从一次线上事故里学来的——当时一个受检异常导致部分数据没回滚，对账对了一整晚。

5.3 接口限流与幂等控制

限流和幂等也是AOP的经典场景。以幂等为例，思路是用注解标记需要幂等的方法，切面里根据业务key去Redis查是否已处理。

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface Idempotent { String key() default ""; int expire() default 10; }

切面里用@Around，在proceed()之前用SETNX抢占key，抢不到就抛重复提交异常，抢到了执行完再决定是否释放。这里有个细节：如果业务执行失败，应该释放key允许重试；如果成功，则保留key到过期。这个逻辑用try-catch配合就能实现，但要注意释放key的操作本身也可能失败，得加兜底。

5.4 权限校验与数据脱敏

权限校验用AOP也很自然。定义一个@RequirePermission("user:delete")注解，切面里从当前登录上下文取用户权限，比对不通过就抛异常。数据脱敏则是反过来，在返回结果上做处理，比如手机号中间四位打码、身份证号只留前后。

脱敏切面有个坑：如果返回的是分页对象或者嵌套结构，直接改返回值可能改不动。因为很多返回对象是不可变的，或者嵌套层级很深。我的做法是，脱敏逻辑尽量放在序列化层（比如Jackson的自定义序列化器），AOP只负责标记哪些字段需要脱敏，不直接改对象。这样职责更清晰，也不容易出并发问题。

6. 常见问题排查与避坑清单

6.1 切面不生效的排查思路

切面不生效是最高频的问题，我整理了一套排查顺序，按这个走基本能定位。

我遇到最多的是第2项和第5项。第2项是因为很多人以为@Aspect就够了，其实它只是个标记，还得让Spring扫描到，所以@Component不能少。第5项就是自调用，前面讲过解法了。

6.2 环绕通知里异常处理的坑

环绕通知里如果自己catch了异常不往外抛，上层就感知不到，事务也不会回滚。看这段代码：

@Around("@annotation(...)") public Object around(ProceedingJoinPoint pjp) throws Throwable { try { return pjp.proceed(); } catch (Exception e) { log.error("异常", e); return null; // 危险！异常被吞了 } }

这样写，目标方法抛异常后返回null，调用方以为成功了，事务也不会回滚。正确做法是记录日志后原样抛出：

} catch (Exception e) { log.error("异常", e); throw e; }

如果确实需要转换异常类型，也要抛出一个新的异常，而不是返回null。这个坑我在早期项目里踩过，导致一个订单状态没回滚，排查了很久。

6.3 切面性能与循环依赖

切面本身有性能开销，尤其是环绕通知，每次调用都要走代理。如果切点范围过大，比如切了整个service包，那每个方法调用都要过一遍切面逻辑。我的建议是：

• 切点尽量精确，别用全匹配。
• 切面逻辑尽量轻量，别在切面里做重IO操作。
• 高频调用的方法（比如缓存读取）慎用切面。

另外，切面和循环依赖有时会互相影响。如果两个Bean互相注入，其中一个还被AOP代理，Spring在创建代理时可能拿不到完整的依赖，导致启动报错。这种情况通常需要调整依赖关系，或者用@Lazy延迟注入来打破循环。

6.4 一个容易被忽略的细节：切面里的this

在切面类里，this指向的是切面对象本身，不是目标对象。如果你想在切面里获取目标对象的信息，要用pjp.getTarget()。想获取目标方法的注解，要用MethodSignature：

MethodSignature signature = (MethodSignature) pjp.getSignature(); Method method = signature.getMethod(); MyAnnotation ann = method.getAnnotation(MyAnnotation.class);

注意，这里拿到的method是接口方法还是实现类方法，取决于代理方式。JDK代理拿到的是接口方法，CGLIB拿到的是实现类方法。如果注解加在实现类方法上而用的是JDK代理，可能拿不到注解。这也是为什么Spring Boot默认改用CGLIB的原因之一。

7. 我个人的一些使用心得

AOP这东西，用好了是利器，用滥了是灾难。我给自己定了几条规矩，分享出来供参考。

第一条，切面只做横切关注点，不碰业务逻辑。日志、事务、权限、限流、缓存，这些是切面的地盘；业务规则、数据计算、流程编排，这些老老实实写在Service里。我见过有人在切面里改业务参数、拼装返回值，结果代码逻辑散落在各处，维护起来极其痛苦。

第二条，注解匹配优先于包路径匹配。注解是显式的，谁被增强一目了然；包路径是隐式的，容易误伤也容易漏。除非是全局性的需求，否则我基本都用注解。

第三条，切面逻辑要能扛住异常。切面里的代码一旦抛异常，可能直接影响主流程。所以切面里的日志、监控、缓存操作，都要做好异常兜底，不能让切面的问题变成业务的问题。

第四条，写完切面一定要写测试。AOP的生效依赖代理，单元测试里直接new对象是测不出切面的。要用@SpringBootTest启动容器，注入代理对象来测。我一般会写一个测试，验证通知确实执行了，比如在切面里往一个List里塞标记，测试里断言这个List非空。

最后再分享一个小技巧：调试切面时，可以在切面里打印pjp.getSignature().toLongString()，它会输出完整的方法签名，包括返回类型、包名、参数类型。排查切点匹配问题时，把这个输出和切点表达式对照，一眼就能看出哪里对不上。

AOP的进阶方向还有很多，比如多个切面的顺序编排、切面与响应式编程的结合、自定义切点注解的元注解处理等等。但把这篇里的基础打牢，后面那些都是水到渠成的事。真正把AOP用顺手之后，你会发现很多原本要写一堆重复代码的地方，现在一个注解就解决了，那种感觉还是挺爽的。