工作中应该都遇到过这种需求方法已经确定要拦截了但还得分情况讨论——同一个方法参数是管理员ID时走审计日志参数是普通用户ID时直接放行同一个更新接口传过来的某个字段满足条件才需要特殊处理不满足就不管。这种“方法确定、参数不定才能决定是否织入逻辑”的需求用 execution 表达式这种静态切点很难写Spring 专门留了一个类就是 DynamicMethodMatcherPointcut。这篇文章我会先讲清楚它的运行机制再带出一个 Spring Boot 可直接运行的示例工程最后把动态切点常见的坑和性能问题一起捋一遍。适合正在学 Spring AOP、或者想在项目里做精细切面控制的开发者参考。1. DynamicMethodMatcherPointcut到底解决了什么问题1.1 Spring AOP的切点由两个部分拼出来刚开始学 Spring AOP 的时候很多人以为切点就是 execution 表达式那一串字符串。其实从接口设计来看Spring 的 Pointcut 从来都是两段式一段管“类”一段管“方法”。Pointcut 接口的定义拆开看就是 getClassFilter() 和 getMethodMatcher() 两个方法。ClassFilter 负责判断目标对象是不是你要处理的类型比如只拦截 UserService 相关的类MethodMatcher 负责判断具体方法是否满足条件比如方法名是不是 updateUser、方法上有没有某个注解。只有两个条件同时满足这个 Advisor 才会对当前方法生效。这个设计看起来简单但实际使用时不注意的人特别多。很多人自定义切点只关注 MethodMatcher以为方法匹配过了就完事。结果容器里其他类的同名方法也被误拦截了排查半天才发现是 ClassFilter 没限定。DynamicMethodMatcherPointcut 这个抽象类默认把 ClassFilter 设置成了 ClassFilter.TRUE也就是“所有类都放行”。这是个很方便的默认行为但也意味着如果你不重写 getClassFilter()你的动态切点会作用到容器里所有 Bean 的所有方法上。1.2 为什么“根据参数值决定是否拦截”必须走动态匹配MethodMatcher 里面有个方法专门用来区分静态匹配和动态匹配。在老版本 Spring 里它叫 isRuntime()Spring 5 之后改名为 dynamic()方法名虽然变了语义是一样的返回 true表示这个匹配器在每次方法调用时都要重新检查参数返回 false表示只要方法签名符合就行参数不影响结果。execution 表达式包括 Spring 里常用的 annotation、within 这些 AspectJ 切点表达式本质都是静态匹配。它们在 Bean 实例化阶段、代理创建的时候就会算好结果后续方法调用直接复用不会再去判断参数。这是它们性能好的原因但也是它们的边界所在——你没法在 execution 表达式里写“当第一个参数等于 1 的时候才拦截”这种逻辑。DynamicMethodMatcherPointcut 就是专门补这个缺口的。它内部已经实现了 dynamic() 方法并返回 true你只需重写一个带参数的三参 matches() 方法每次目标方法调用时Spring AOP 都会把 Method、目标 Class、方法实参 Object... args 传进来由你来做最终裁决。1.3 动态匹配在调用链路上的执行时机理解动态切点最关键的是搞清楚它在方法调用链路上的位置。Spring AOP 代理对象在创建时会先从容器里收集所有 Advisor然后对每个方法做一次静态匹配。静态匹配通过后如果 MethodMatcher.dynamic() 返回 true这个 Advisor 不会立刻被绑定到方法上而是进入“待定”状态。真正方法被调用时代理对象会执行拦截器链。走到这个 Advisor 的匹配环节Spring 会调用三参 matches(Method, Class, Object...) 方法把当前方法的实参传进去。返回 true通知执行返回 false这个 Advisor 直接跳过方法继续走后面的链路。注意一个细节动态匹配的是“调用时”的参数不是“方法定义时”的形参类型。所以如果你的方法有多个重载动态切点匹配时一定要考虑 args 里的实际参数类型和顺序否则很容易出现类型转换异常或者匹配错位。2. 环境准备Spring Boot项目一秒钟搭起来2.1 Maven依赖spring-boot-starter-aop就够了动态切点属于 Spring AOP 的核心能力在 Spring Boot 工程里只需要引入一个起步依赖即 spring-boot-starter-aop。这个依赖会传递引入 spring-aop 和 aspectjweaver前者提供 Pointcut、Advisor、MethodInterceptor 这些核心 API后者负责 AspectJ 表达式的解析支持。如果你用的是 Spring Boot 2.x对应 Spring Framework 5.x用 Spring Boot 3.x 则对应 Spring Framework 6.x。两个版本在 AOP 接口的包名上没有变化但 MethodMatcher 里 isRuntime() 和 dynamic() 的命名切换要留意网上很多老文章还在用 isRuntime()在新版本里编译会直接报错。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency不需要额外引入 web 依赖这个示例只是验证切点逻辑启动一个 Spring Boot Application 就够了。2.2 先理解Spring Boot的AOP自动配置机制Spring Boot 引入 spring-boot-starter-aop 后会触发 AopAutoConfiguration 自动配置。它的核心作用相当于帮你在容器里开启 EnableAspectJAutoProxy创建 AnnotationAwareAspectJAutoProxyCreator这个后置处理器会扫描容器里所有的 Advisor 和 Aspect 切面对匹配的 Bean 生成代理对象。我做这个示例时配置类里没有手动加 EnableAspectJAutoProxy发现动态切点也能正常工作。因为 Spring Boot 的自动配置已经把这个开关打开了。但如果你不是在 Spring Boot 环境或者你关闭了自动配置那就要记得手动加这个注解。这里也提醒一下如果你用了 Spring Cloud 或者其他框架个别场景下 AOP 自动配置会被排除这时候动态切点一样不生效排查顺序应该先从这些基础配置看起。2.3 项目结构规划示例功能很简单模拟一个用户服务 UserService其中有 updateUser 方法用于更新用户信息。我们的需求是当 updateUser 的第一个参数 userId 等于 1 时认为这是管理员操作需要在方法前后输出审计日志userId 为其他值时方法直接执行不加日志。为了让切点逻辑更完整UserService 里再加一个 deleteUser 方法。deleteUser 即使第一个参数也是 1也不应该被拦截——因为动态切点的静态匹配部分已经限定了只有 updateUser 方法才能进入动态匹配环节。这样就能同时验证“方法不匹配”和“参数不匹配”两条路径。项目包结构如下全部放在默认包下即可方便演示UserService.java业务类被代理对象UserOperationPointcut.java自定义动态切点AuditAdvice.java环绕通知实现 MethodInterceptorAopConfig.java配置类组装 Advisor 并声明 BeanDemoRunner.java启动时自动执行测试方法DemoApplication.javaSpring Boot 启动类3. 完整示例代码从切点到通知再到Advisor3.1 业务类一个简单的用户服务为了演示方便UserService 直接定义成无接口的普通类方法里用最简单的打印语句模拟业务逻辑。这里故意不用接口是为了避免 JDK 动态代理带来的注入类型问题后面我会专门讲接口场景下容易踩的坑。import org.springframework.stereotype.Component; Component public class UserService { public void updateUser(Long userId, String name) { System.out.println([UserService] 更新用户信息userId userId , name name); } public void deleteUser(Long userId) { System.out.println([UserService] 删除用户userId userId); } }这里有个值得思考的细节为什么是 Long userId而不是 long userId因为动态切点在匹配三参 matches 方法时拿到的 args 数组是目标方法被调用时的实参。如果方法是 updateUser(Long, String)那 args[0] 就是 Long如果方法是 updateUser(long, String)那 args[0] 就是包装类型 Long这是自动装箱导致的。后面判断参数类型时我会按包装类型处理避免不必要的类型转换异常。3.2 自定义切点继承DynamicMethodMatcherPointcut这是整个示例的核心类。我重写了两个方法两参 matches 做静态层面的方法名过滤三参 matches 做运行时参数判断。import org.springframework.aop.ClassFilter; import org.springframework.aop.support.DynamicMethodMatcherPointcut; import java.lang.reflect.Method; public class UserOperationPointcut extends DynamicMethodMatcherPointcut { Override public ClassFilter getClassFilter() { return clazz - UserService.class.isAssignableFrom(clazz); } Override public boolean matches(Method method, Class? targetClass) { return updateUser.equals(method.getName()); } Override public boolean matches(Method method, Class? targetClass, Object... args) { if (args null || args.length 0) { return false; } Object firstArg args[0]; if (!(firstArg instanceof Number)) { return false; } long userId ((Number) firstArg).longValue(); return userId 1L; } }这里我把 getClassFilter 也重写了限定只处理 UserService 类型的 Bean。这个操作在官方文档里通常不会单独强调但实际工程里非常关键。如果不重写ClassFilter.TRUE 会让这个切点作用到容器中所有 Bean只要方法名叫 updateUser 且第一个参数等于 1就会被拦截。两参 matches 方法决定哪个方法可以进入动态匹配。这里通过 method.getName() 限定了只匹配 updateUser。这样 deleteUser 方法就不会被误伤即使它的参数也是 1。三参 matches 才是真正跑在调用链里的动态逻辑。还要强调一点两参 matches 在整个代理生命周期中只会执行有限次数通常是在代理创建和 Advisor 链路构建时。而三参 matches 在每次方法调用时都会执行所以复杂度高的运算不要放在三参 matches 里。这个性能问题后面专门讲。3.3 实现环绕通知MethodInterceptor增强逻辑Spring AOP 的编程式增强最底层接口是 org.aopalliance.intercept.MethodInterceptor也就是 AOP 联盟定义的环绕通知。它和 Aspect 里的 Around 本质上是同一个东西Spring 内部会把 Around 方法也转换成 MethodInterceptor 来执行。这里定义审计日志通知打印方法入参、调用耗时和返回值。通过 invocation.proceed() 放行业务方法这行代码是整个通知的灵魂漏掉它方法就不会执行了。import org.aopalliance.intercept.MethodInterceptor; import org.aopalliance.intercept.MethodInvocation; import java.util.Arrays; public class AuditAdvice implements MethodInterceptor { Override public Object invoke(MethodInvocation invocation) throws Throwable { String methodName invocation.getMethod().getName(); Object[] args invocation.getArguments(); System.out.println([AuditAdvice] 审计开始method methodName , args Arrays.toString(args)); long start System.currentTimeMillis(); Object result invocation.proceed(); long cost System.currentTimeMillis() - start; System.out.println([AuditAdvice] 审计结束method methodName , cost cost ms, result result); return result; } }MethodInvocation 里可以拿到当前目标方法、目标对象、参数数组和 AOP 联盟的代理对象。实际项目里审计日志通常需要记录操作用户、IP、操作时间这些信息可以通过 RequestContextHolder 从 ThreadLocal 里取和这里的动态切点配合起来很自然。3.4 组装Advisor用DefaultPointcutAdvisor把两者绑起来切点和通知本身是独立的真正生效需要组合成 Advisor。Spring 里最常用的实现类就是 DefaultPointcutAdvisor它通过 setPointcut 绑定切点、setAdvice 绑定通知。这里用 Bean 显式声明这些对象而不是用 Component 扫描。原因很简单切点和通知类里没有附加的组件逻辑直接 new 出来可读性更高也方便在配置里看到绑定关系。import org.springframework.aop.support.DefaultPointcutAdvisor; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class AopConfig { Bean public UserOperationPointcut userOperationPointcut() { return new UserOperationPointcut(); } Bean public AuditAdvice auditAdvice() { return new AuditAdvice(); } Bean public DefaultPointcutAdvisor auditAdvisor(UserOperationPointcut userOperationPointcut, AuditAdvice auditAdvice) { DefaultPointcutAdvisor advisor new DefaultPointcutAdvisor(); advisor.setPointcut(userOperationPointcut); advisor.setAdvice(auditAdvice); advisor.setOrder(1); return advisor; } }setOrder(1) 是为了控制多个 Advisor 同时存在时的执行顺序。如果工程里还有其他切面order 值越小越先执行。这个例子只有一个切面不设置也可以但写上能让后来维护的人明确知道这是有意识地安排了优先级。这里有个需要重点理解的点Spring Boot 自动代理机制会扫描容器中的 Advisor Bean。只要 auditAdvisor 存在于容器中动态切点就会作用于所有匹配的 Bean 上。也就是说你不必在每个业务方法上手动标记任何注解切点自己会根据方法名和参数值决定要不要织入增强逻辑。3.5 启动入口设计CommandLineRunner打印运行结果为了不引入单元测试依赖我直接用 CommandLineRunner 在 Spring Boot 启动后跑一遍验证逻辑。DemoRunner 注入 UserService分别调用几种典型场景用日志展示动态切点的行为。import org.springframework.boot.CommandLineRunner; import org.springframework.stereotype.Component; Component public class DemoRunner implements CommandLineRunner { private final UserService userService; public DemoRunner(UserService userService) { this.userService userService; } Override public void run(String... args) { System.out.println( 业务调用开始 ); userService.updateUser(100L, 张三); System.out.println(---------- 分隔线 ----------); userService.updateUser(1L, 管理员); System.out.println(---------- 分隔线 ----------); userService.deleteUser(1L); System.out.println( 业务调用结束 ); } }第一种调用userId 是 100动态匹配返回 false方法直接执行。第二种调用userId 是 1符合动态匹配条件审计日志应该出现。第三种调用虽然 userId 是 1但方法名是 deleteUser静态匹配这一层就被拦住了审计日志也不该出现。4. 运行效果与原理复盘参数不同链路不同4.1 控制台日志解读启动 Spring Boot 应用控制台会输出如下日志 业务调用开始 [UserService] 更新用户信息userId100, name张三 ---------- 分隔线 ---------- [AuditAdvice] 审计开始methodupdateUser, args[1, 管理员] [UserService] 更新用户信息userId1, name管理员 [AuditAdvice] 审计结束methodupdateUser, cost0ms, resultnull ---------- 分隔线 ---------- [UserService] 删除用户userId1 业务调用结束 从日志可以很直观地看到第二次调用前后出现了审计日志而第一次和第三次没有。这说明动态切点的两条判断路径都生效了第一次是“方法匹配但参数不匹配”第三次是“参数匹配但方法不匹配”。动态匹配器和静态方法名过滤在链路中共同决策缺一不可。如果你跑出来的结果和这个不一致最常见的原因是 UserService 被 CGLIB 代理了但 DemoRunner 注入的却是别的实例。后面常见问题部分我会详细说。4.2 方法匹配顺序类过滤→静态匹配→动态匹配从日志反推 Spring 内部的处理流程整个匹配链路其实有三层第一层是类过滤。代理对象在创建时Spring 会对候选 Advisor 做 canApply 判断调用 ClassFilter.matches(targetClass)。我们的切点限制了只有 UserService 相关的类才可能匹配所以容器里的其他 Bean 从一开始就不会被这个 Advisor 影响。第二层是静态匹配。代理对象的每个方法都会交给 MethodMatcher.matches(Method, Class) 判断一次如果返回 false这个 Advisor 直接和当前方法解绑。我们的示例里 deleteUser 在这层就被过滤掉了。第三层才是动态匹配。每次方法调用时Spring 执行拦截器链走到这个 Advisor调用三参 matches把当前调用的实参传进去。返回 true 才执行增强逻辑。这个“两参匹配一次、三参匹配每次”的机制翻译成人话就是能提前决定的事提前决定不能提前决定的事留到调用时再定。Spring AOP 的优化思路一直是这样。4.3 与静态切点对比性能差异和使用边界静态切点比如 execution(* com.example...(..))在代理创建阶段就完成了匹配方法调用期间零判断开销。动态切点则每次调用都要跑一遍三参 matches哪怕逻辑很简单也有反射调用、数组遍历、类型判断的额外成本。所以我的建议很明确能静态匹配绝不动态匹配。动态匹配只适用于那种“必须依赖运行时参数才能决策”的场景比如根据请求中的用户角色决定是否开启链路追踪、根据某个关键业务字段判断是否触发数据迁移、根据操作类型决定是否发送消息通知。这些场景里参数值本身就是规则的一部分不拿参数做判断根本没法实现。如果只是想在某个方法上加日志execution 表达式加 Around 就够了完全没必要上动态切点。动态匹配器的价值在于灵活性不在于性能用错地方就是给系统埋雷。5. 常见问题与排查实录全是踩过的坑5.1 切点匹配了但通知没进来这个问题的典型表现是业务方法执行了日志里没有审计输出但你把断点打到三参 matches 里发现它确实被调用了。这说明切点的匹配逻辑已经执行但 Advisor 没有被应用或者应用了却被其他机制跳过了。第一优先级排查 Advisor 是否在容器里。你可以通过 ApplicationContext.getBean(DefaultPointcutAdvisor.class) 验证。如果找不到 Bean说明配置类没被扫描到或者 Configuration 类所在的包路径不在启动类子包下。第二优先级排查代理是否生效。Spring Boot 默认会代理匹配的 Bean但如果 UserService 本身是 final 类CGLIB 无法代理切点永远不会生效。还有一个隐蔽的问题如果你在切点里用了 Component 注解让 Spring 自动扫描比如把切点类标成 Component然后在配置类里又手动 new 了一个切点实例容器里就有两个切点 Bean。真正生效的可能是你没绑定的那个而你配置的 Advisor 绑定的是另一个。排查时要留意容器里是否存在重复实例。5.2 自调用导致切点失效这个问题是所有 Spring AOP 用户都会遇到的经典问题。UserService 里如果有一个 public 方法内部直接调用另一个方法比如 updateUser 方法内部调用 this.deleteUser那么 deleteUser 不会经过代理对象而是直接调用原始对象的方法。因为 this 指向的是目标对象本身不是代理对象。Spring AOP 基于代理实现内部自调用天然不走切点。解决办法有几种一是注入 self 代理也就是在 Bean 里注入 ApplicationContext 然后 getBean(自己.class)二是使用 AopContext.currentProxy()前提是在配置里开启 exposeProxy 属性三是把需要切点的方法拆分到另一个 Bean 中通过容器获取它。三种方式按团队习惯选我个人更推荐第三种结构更清晰。这个坑和 DynamicMethodMatcherPointcut 本身没有直接关系但正因为动态切点匹配的是参数值如果你在测试时用自调用验证参数场景很容易误以为切点逻辑写错了浪费大量时间在非目标问题上。5.3 动态匹配的性能开销与优化有人可能会问三参 matches 每次调用都执行性能真的会拖垮系统吗答案取决于 matches 方法里写了什么。如果你只是比较几个参数值一次匹配的开销可能连微秒都不到几乎可以忽略不计。但如果你在 matches 里查数据库、调外部接口、做复杂正则那问题就大了。每调用一次业务方法这些耗时操作就跟着执行一次。更麻烦的是matches 执行失败抛出的异常可能影响正常业务链路甚至是那些你不想拦截的调用。我的优化思路有两个。其一静态部分是能过滤越多越好在两参 matches 里尽可能收紧方法范围让动态 matches 尽量少被调用。其二动态 matches 里只读取参数做轻量判断不要在匹配阶段做任何副作用操作。如果确实需要根据参数查询数据库可以去通知方法里做因为通知方法只会在真正需要增强时执行比 matches 省得多。5.4 切点匹配范围过大造成误伤DynamicMethodMatcherPointcut 默认的 ClassFilter.TRUE 是个不小的隐患。假设容器里有另一个 Bean比如 OrderService它也有一个 updateUser(Long, String) 方法那么当参数是 1 时你的审计日志会同样作用到 OrderService 上。这不是切点逻辑错了而是因为 ClassFilter 没有限制目标类型动态匹配器成为了一种“全局规则”。解决方式就是我示例里写的重写 getClassFilter 方法用 clazz - UserService.class.isAssignableFrom(clazz) 限定范围。如果业务场景更复杂还可以用注解限定比如 clazz - clazz.isAnnotationPresent(Auditable.class)。同理如果你希望多个不同业务类的方法都走同一个动态切点可以用接口或父类做收口。但要注意 isAssignableFrom 和 equals 的区别前者包含子类后者只匹配自身。5.5 JDK代理与CGLIB代理的选择Spring Boot 2.x 之后默认的代理策略是优先用 CGLIB因为 proxyTargetClass 默认值变成了 true。但在更早版本或者显式配置了 proxyTargetClassfalse 时如果目标类实现了接口Spring 会使用 JDK 动态代理。JDK 动态代理要求所有注入方都使用接口类型。比如 UserService 实现了 UserServiceInterface而 DemoRunner 里注入的是 UserService实现类启动时就会报错因为代理对象是 Proxy 的实例类型上不是 UserService。这个报错信息通常比较直观看到类似 BeanNotOfRequiredTypeException 就能定位。CGLIB 代理没有接口限制但如果方法或类是 final 的CGLIB 也无法代理。final 方法在 CGLIB 里不会进入拦截器链动态切点自然也不生效。写代码时如果你预感到某方法可能要被 AOP 增强就别顺手标 final这个习惯能省很多排查时间。6. 一些后续可以延伸的玩法6.1 结合自定义注解做更灵活的控制DynamicMethodMatcherPointcut 虽然动态但它判断目标方法通常还是靠方法名或参数类型。工程代码越多这种字符串匹配越脆弱重构时方法一改名切点就失灵了。更优雅的做法是引入自定义注解比如 Audited然后在两参 matches 里通过 method.isAnnotationPresent(Audited.class) 做判断。这样做有几个好处第一切点和方法名解耦方法改名不影响匹配第二你可以在注解里配置属性比如 actionType、level让动态 matches 读取注解属性来决定是否拦截第三类和方法的语义更清晰维护的人一眼就能看出来哪些方法被切点覆盖。6.2 与SpEL表达式结合实现动态判断很多团队喜欢用 SpEL 表达式做规则配置。动态切点的 matches 方法是纯 Java 逻辑但你可以在这个方法里解析 SpEL 表达式把规则外置到配置中心。比如方法入参是一个对象 Object payload三参 matches 里可以写 SpelExpressionParser 来解析 payload.amount 1000 这样的表达式命中结果决定是否调用通知。这套方案在规则经常变化的系统中很实用但要注意解析性能最好把表达式预先编译并缓存起来不要在每次方法调用时都重新解析一遍。6.3 什么情况不建议用DynamicMethodMatcherPointcut如果你的需求里根本没有“根据参数值决策”这一项那就老老实实写 execution 表达式。如果只是想在方法上挂一个注解来开关功能Aspect 加 annotation 更直观。如果切点逻辑是纯静态方法名和类名匹配StaticMethodMatcherPointcut 更合适因为它不会触发每次调用的动态检查。动态切点是把好刀但好刀通常意味着更高的使用成本。它最大的成本是“每次调用都跑匹配逻辑”其次是匹配逻辑写复杂后难以调试。我在实际项目里见到过把多次 RPC 调用写进三参 matches 的案例线上接口从 20ms 直接飙到 400ms最后排查定位到切点代码才发现问题。这给我的体会是动态切点要尽量轻能两行代码判断完的事不要写两百行。如果匹配规则确实很重宁可把这个判断放到异步线程或者本地缓存里也不要阻塞在每次方法调用的链路上。回到你手头的需求如果现在遇到的是“同一方法在不同参数下要走不同逻辑”这种场景DynamicMethodMatcherPointcut 确实是 Spring AOP 里最贴合的工具。我建议你直接把示例代码跑起来先观察三参 matches 在调用链路上被触发的时机再根据自己的业务调整匹配规则后续维护时就不会再被这种切点问题卡住了。