@Aspect @Component public class LoggingAspect {
@Pointcut("execution(* com.example.service.*.*(..))")
public void serviceLayer() {}
@Before("serviceLayer()")
public void logBefore(JoinPoint joinPoint) {
// 前置通知逻辑
}
}
2.1 方法执行切点表达式语法
execution表达式是Spring AOP中最常用的切点表达式，它直接对应方法的执行时机。这种表达式的威力在于能够精确描述方法的各个组成部分。
基本语法格式如下：
execution(修饰符 返回类型 包名.类名.方法名(参数类型) 异常类型)
其中修饰符和异常类型通常可以省略，让表达式更加简洁。
来看几个实际例子：
execution(* com.example.service.UserService.*(..))
匹配UserService类中的所有方法，不考虑返回类型和参数。
execution(public void update*(*))
匹配所有以update开头的公有方法，要求返回void且接受一个任意类型的参数。
我曾经在一个用户管理系统中使用过这样的表达式：
execution(* com.project.user.*.save*(..))
这个表达式成功拦截了user包下所有以save开头的方法，包括UserService.saveUser()、UserRepository.saveProfile()等。这种模式匹配的能力确实很实用，避免了为每个方法单独配置切点的繁琐。
2.2 类型匹配切点表达式语法
类型匹配关注的是类或接口层面的筛选，它不关心具体的方法细节。within表达式在这方面表现出色。
常见的类型匹配表达式：
within(com.example.service.*)
匹配service包下的所有类，但不包括子包。
within(com.example.service..*)
使用双点号匹配service包及其所有子包下的类。
within(@org.springframework.stereotype.Service *)
匹配所有被@Service注解标记的类。
类型匹配特别适合处理那些具有相同注解或位于特定包结构的类群组。我记得有次需要为所有Controller添加请求日志，使用within(@org.springframework.web.bind.annotation.RestController *)就轻松搞定了，不需要逐个方法去匹配。
2.3 参数匹配切点表达式语法
参数匹配让我们能够基于方法的参数来筛选连接点。args表达式在这方面提供了精细的控制能力。
参数匹配的典型用法：
execution(* *(..)) && args(String, int)
匹配接受一个String和一个int参数的方法。
execution(* com.example.service.*.*(..)) && args(javax.servlet.http.HttpServletRequest,..)
匹配service包中那些第一个参数为HttpServletRequest的方法。
参数匹配在处理特定场景时特别有用。比如在Web应用中，你可能只想拦截那些包含HttpServletRequest参数的方法来进行请求信息记录。这种精确度是其他匹配方式难以提供的。
2.4 复合切点表达式语法
实际项目中，单一表达式往往无法满足复杂的需求。复合切点通过逻辑运算符组合多个表达式，实现更精确的匹配。
Spring AOP支持三种逻辑运算符： - &&（与）：两个条件都满足 - ||（或）：满足任意一个条件 - !（非）：不满足指定条件
复合表达式示例：
execution(* com.example.service.*.*(..)) && !execution(* com.example.service.ConfigService.*(..))
匹配service包中除ConfigService类之外的所有方法。
within(com.example.web..*) || within(com.example.api..*)
匹配web包和api包下的所有类。
复合表达式的组合能力几乎无限。我曾经需要为业务层方法添加性能监控，但要排除几个特定的配置读取方法。使用&&和!运算符的组合，很优雅地解决了这个问题。这种灵活性让切点表达式能够适应各种复杂的业务场景。
切点表达式的语法体系设计得很完善，从简单的方法匹配到复杂的逻辑组合，每个层级都考虑到了实际开发需求。掌握这些语法规则，你就能在AOP的世界里游刃有余。 public class CustomBusinessPointcut implements Pointcut {
@Override
public ClassFilter getClassFilter() {
return clazz -> clazz.getSimpleName().endsWith("Service");
}
@Override
public MethodMatcher getMethodMatcher() {
return new StaticMethodMatcher() {
@Override
public boolean matches(Method method, Class<?> targetClass) {
return method.getName().startsWith("process");
}
};
}
}
public class DynamicAccessPointcut extends DynamicMethodMatcherPointcut {
private SecurityService securityService;
@Override
public boolean matches(Method method, Class<?> targetClass, Object[] args) {
// 根据方法参数动态决定是否拦截
return securityService.hasAccess((User) args[0]);
}
}
@Pointcut("execution( com.company.business..Service.*(..)) && " +
"!@annotation(com.company.annotation.NoLog)")
public void businessServiceMethods() {}
6.1 切点表达式匹配失败排查方法
切点表达式匹配失败是开发过程中最让人头疼的问题之一。明明觉得表达式写对了，但切面就是不生效。
检查表达式语法是最基本的步骤。Spring AOP的切点表达式有严格的语法规则，比如execution表达式中方法返回类型、包路径、方法名、参数列表的顺序都不能错。我遇到过这样的情况：一个同事写的切点表达式漏掉了方法参数部分的括号，导致整个切面失效，排查了半天才发现是这个小细节。
包路径匹配问题也很常见。使用".."表示任意子包时，要注意它匹配的是零个或多个层级的包。有时候你以为匹配到了某个包下的所有类，实际上因为包层级关系没匹配上。建议先用简单的表达式测试，确认匹配范围后再逐步完善。
代理机制的影响不容忽视。Spring AOP基于代理实现，只有通过Spring容器获取的Bean才会被切面拦截。如果你直接new一个对象调用方法，切面是不会生效的。这个坑我踩过——在单元测试中直接实例化对象测试切面，结果怎么都不生效，后来才意识到是代理的问题。
排查工具的使用能事半功倍。Spring提供了调试模式，可以输出详细的切点匹配信息。在开发阶段开启调试日志，能清楚地看到每个切点匹配了哪些方法，哪些方法被排除了。
6.2 切点表达式性能问题分析
切点表达式的性能影响往往被低估，直到系统压力测试时才暴露出来。
表达式复杂度直接影响性能。包含大量逻辑运算符的复合表达式，特别是使用||（或）运算时，Spring需要遍历所有可能的匹配项。曾经有个项目使用了一个包含十多个||运算的切点表达式，在方法调用频繁的场景下CPU使用率异常升高。简化表达式后性能立即改善。
避免过度宽泛的匹配范围。像"execution( com..(..))"这样的表达式会匹配项目中几乎所有方法，不仅影响性能，还可能拦截到不期望的方法。应该尽量精确指定包路径和方法模式。
切点表达式的编译和缓存机制值得了解。Spring在启动时会编译切点表达式，并将匹配结果缓存起来。这意味着切点表达式的复杂度主要影响启动时间，运行时性能影响相对较小。但如果切点表达式依赖运行时参数，缓存效果就会打折扣。
性能监控工具能帮助定位问题。使用APM工具监控方法执行时间，如果发现切面处理时间占比过高，就要考虑优化切点表达式了。一般来说，切面处理时间不应超过方法本身执行时间的5%。
6.3 切点表达式维护最佳实践
切点表达式的维护是个长期工作，好的实践能让后续维护轻松很多。
命名切点是维护的基础。给每个切点起一个有意义的名字，比如"businessServiceMethods"比"pointcut1"要好理解得多。几个月后回来看代码，你还能清楚地知道这个切点是干什么的。
模块化切点表达式很有帮助。将常用的匹配模式提取成独立的切点，然后在其他切点中引用。这样当匹配规则需要修改时，只需要改一个地方。比如把包路径基础部分定义成一个切点，其他业务切点都基于这个基础切点构建。
文档和注释必不可少。在复杂的切点表达式旁边添加注释，说明这个切点的意图、匹配范围、排除规则等。团队新成员接手时，这些注释能节省大量理解成本。
版本控制中的切点变更要特别小心。修改生产环境的切点表达式时，要充分测试确保不会意外拦截或漏掉关键方法。建议每次修改都记录在变更日志中，说明修改内容和影响范围。
6.4 切点表达式版本兼容性处理
随着系统迭代升级，切点表达式的版本兼容性问题逐渐显现。
Spring版本升级带来的变化需要关注。不同版本的Spring AOP在切点表达式解析上可能有细微差别。从Spring 4升级到Spring 5时，我们就遇到过切点表达式行为不一致的情况。升级前最好在测试环境充分验证现有切点的匹配效果。
JDK版本变化的影响不容忽视。特别是使用基于JDK动态代理的AOP时，高版本JDK可能对代理机制有优化或调整。使用CGLIB代理相对稳定一些，但也要注意版本兼容性。
第三方库更新可能影响切点匹配。当项目依赖的库更新版本时，其中的类名、方法名可能发生变化，导致原有的切点表达式失效。建立完善的回归测试用例能及时发现这类问题。
向后兼容的切点设计很重要。在定义切点时，考虑未来可能的变化，尽量使用相对稳定的匹配模式。比如基于自定义注解的切点比基于包路径的切点更稳定，因为注解通常不会随意改动。
渐进式迁移策略能降低风险。当需要修改重要的切点表达式时，不要一次性全改，可以新旧表达式并行运行一段时间，通过日志对比两者的匹配结果，确认无误后再移除旧的表达式。这种做法虽然麻烦，但能避免线上事故。
