切入点配置是Spring AOP中最核心也最容易被绕晕的环节，它决定了哪些方法会被增强逻辑拦截，直接给出结论：掌握execution表达式的语法骨架和通配符组合规则，就能解决绝大多数配置需求。 这篇文章从实际开发场景出发，把切入点配置的常见写法、易错点和排查思路一次说清。
切入点表达式怎么写最常用：先拆解语法骨架
很多初学者看到一长串切入点表达式就头皮发麻，其实拆开来看就五个部分，以最经典的 execution(public com.example.service..(..)) 为例，它依次是：修饰符、返回类型、包名路径、类名方法名、参数列表。
修饰符与返回类型的搭配逻辑
修饰符可写可不写，不写就代表匹配所有访问级别，返回类型必须写， 代表任意返回类型，注意 void 和 的区别：前者只匹配无返回值的方法,后者匹配所有。
- 精确匹配：
execution(public void com.example.UserService.save()) - 模糊匹配：
execution( com.example..(..))
包名路径的粒度控制艺术
包名是切入点配置中变数最大的部分。com.example.service 和 com.example.service. 含义完全不同，前者只匹配该包下的直接类，后者多了一层通配，更关键的是 的使用,它代表包路径的任意层级递归。
- 单层通配：
execution( com.example.service..(..))，匹配service包下所有类的所有方法 - 多层递归：
execution( com.example...(..))，匹配com.example及其所有子包
实际项目中，多层递归写法用得最多，因为业务代码通常按controller、service、dao分层嵌套， 能一次覆盖整个业务包。
参数列表的三种匹配姿势
参数匹配有三种写法，对应不同场景。 匹配任意参数， 匹配恰好一个参数，(String, ..) 匹配第一个参数为String、后续参数任意。
参数匹配有个容易踩的坑：重载方法，如果同一个类有 save(User user) 和 save(User user, String remark) 两个方法，用 execution( save(..)) 会把两个都拦截，用 execution( save(User))
只拦第一个，实际配置时，需要精确控制某个重载方法时,参数列表必须写完整。
execution表达式详解：五种典型场景的配置模板
理解了语法骨架，接下来看具体场景怎么套用，以下五种写法覆盖了日常开发的大部分需求,可以直接参考修改。
拦截某个具体类的所有方法
@Around("execution( com.example.service.OrderService.(..))")
这是最基础的写法，适用于对单一业务类做统一增强，比如记录操作日志，需要注意，这里的 匹配所有方法名，包括私有方法，如果只想匹配公有方法，要写成 execution(public com.example.service.OrderService.(..))。
拦截某个类的指定方法
@Before("execution( com.example.service.OrderService.createOrder(..))")
适用于只增强特定业务动作，比如下单前校验库存，这种写法在电商、交易类系统中非常常见,因为一个类里通常只有个别方法需要特殊处理。
按注解进行切入点配置
@Around("@annotation(com.example.annotation.OperLog)")
基于注解的切入点配置是近年来的主流做法，比按包路径配置更精准、更灵活，它的优势在于：方法级别的控制力，同一类里只有标注了注解的方法才会被拦截,完全不影响其他方法。
拦截Controller层做统一异常处理
@AfterThrowing(pointcut = "execution( com.example.controller...(..))", throwing = "ex")
Controller层通常有多个子包，用 递归匹配是标配，这种配置配合全局异常处理器，能把控制层抛出的异常统一收敛,避免异常信息直接暴露给前端。
组合多个切入点
@Around("execution( com.example.service...(..)) && !execution( com.example.service.impl...(..))")
组合使用 &&、、 三个逻辑运算符，能实现精细控制，比如上面这个表达式，匹配service包下所有方法，但排除impl实现类。实际项目中，这种排除写法常用于避免重复拦截,比如接口和实现类同时被代理时。
通配符与逻辑运算符的实战组合策略
通配符和逻辑运算符是切入点配置的进阶武器，用好了能大幅减少配置量,用错了则可能造成拦截范围失控。
通配符使用中的常见认知误区
和 的区别需要反复强调： 只能匹配一层， 可以匹配多层，在包路径中，com..service 只能匹配 com.xxx.service，匹配不了 com.xxx.yyy.service；而 com..service 能匹配任意中间层级。
业内专家指出，多数切入点配置异常都源于对这两个通配符的误用，尤其是把 当 用,导致本该拦截的方法漏掉。
逻辑运算符的优先级与括号使用
&&、、 三者的优先级顺序是： 最高，&& 次之， 最低，当表达式较复杂时，建议用括号明确优先级,提高可读性。
execution( com.example.service..(..)) && (@annotation(OperLog) || @annotation(AuditLog))
这个表达式表示：匹配service包下所有方法，且方法上标注了OperLog或AuditLog注解，没有括号的话，逻辑会变成：匹配service包下所有方法且标注OperLog，或者匹配所有标注AuditLog的方法,完全变味。
常见切入点配置错误及排查思路
配置了切入点但不生效，这是排查成本最高的问题，按以下顺序检查,多数情况能快速定位：
- 检查AOP依赖是否引入完整，Spring Boot项目需要
spring-boot-starter-aop - 检查切面类是否加了
@Aspect和@Component注解 - 检查切入点表达式是否与目标方法的实际包路径一致
- 检查目标方法是否被final修饰，final方法无法被代理
- 检查代理方式，Spring默认使用JDK动态代理，只代理接口；要代理类需配置
proxy-target-class=true
自调用场景尤其容易出问题，同一个类中方法A调用方法B，B上的切入点不会生效，因为调用发生在代理对象内部，绕过了代理逻辑，解决办法是注入自身代理,或者把方法拆到不同类中。
切入点配置在不同框架版本中的差异与兼容性
Spring Boot 2.x和3.x对AOP的支持没有本质变化，但底层有细微差别，Spring Boot 3.x基于Spring Framework 6，要求JDK 17以上，@EnableAspectJAutoProxy 的默认行为与2.x一致,不需要额外调整。
Spring AOP与AspectJ的切入点配置对比
Spring AOP只支持方法级别的切入点，AspectJ支持字段、构造器、类初始化等更细粒度。对于绝大多数业务系统，Spring AOP的方法级切入点已经完全够用，不需要引入AspectJ的织入编译器，据Spring官方文档说明，Spring AOP的设计目标就是解决企业应用中最常见的方法拦截需求,而非替代AspectJ的全部能力。
切入点配置的调试方法
调试切入点配置最直接的办法是开启日志，在application.properties中配置：
logging.level.org.springframework.aop=DEBUG
启动项目后，控制台会输出所有被代理的Bean和匹配的切入点信息，看到 Applying shared pointcut 字样就说明匹配成功,没看到就要回头检查表达式。
另一个实用技巧是写一个简单的测试用例，用 AopUtils.isAopProxy() 判断目标Bean是否为代理对象,快速验证AOP配置是否生效。
切入点配置常见问题Q&A
切入点配置和通知类型有什么关系？
切入点只负责”在哪里拦截”，通知类型决定”拦截后做什么”，切入点表达式在 @Before、@After、@Around 等注解中都可以使用，同一个切入点可以配合不同通知类型实现不同增强逻辑，实际配置时，通常先定义切入点方法，再在通知注解中引用,这样便于复用和维护。
切入点配置中的异常处理要注意什么？
@Around 通知中，如果方法内部抛出异常，需要谨慎处理，在环绕通知中捕获异常后不重新抛出，会吞掉原始异常导致事务回滚失效，行业共识是：环绕通知中除非有明确的吞异常需求，否则捕获后应重新抛出或包装后抛出，对于 @AfterThrowing 通知，Spring默认只拦截声明抛出异常的方法，如果方法内部catch了异常不抛出,通知不会触发。