Spring AOP与Solon AOP深度对比：机制、体验与选型指南

把 Spring AOP 和 Solon AOP 放在一起对比，本质上是在对比两套不同时代的 Java 应用框架对“横切关注点”工程化的理解。Spring AOP 是 Spring 生态处理日志、事务、安全、监控的核心手段，底层依赖动态代理与 AspectJ 切点表达式；Solon AOP 则是国产轻量框架 Solon 用一套更轻、更快的代理机制解决同一类问题。今天不罗列文档，我从机制实现、开发体验、性能开销、踩坑经验四个角度，把两者的区别拆到代码层面，顺便聊聊什么样的项目适合选哪一边。如果你正在做技术选型，或者身边有人用 Solon 而你对它的 AOP 机制好奇，这篇应该能帮你建立完整的判断框架。

1. 先说清楚：AOP 到底在解决什么问题

1.1 面向切面编程在真实项目里解决什么

AOP（Aspect Oriented Programming）翻译过来叫面向切面编程，很多人第一次接触时被“切面”这个词绕晕了，其实它解决的是一个非常朴素的问题：把散落在业务代码里的重复逻辑，统一收拢到一处处理。

举一个最典型的例子。你的项目里有十几个 Service，每个 Service 都有增删改查方法，领导要求每个方法都必须打日志、必须做耗时统计、必须做权限校验。如果你在每个方法里手写这段逻辑，代码会变成什么样？先打日志、再查权限、再执行业务、最后再打一条结束日志，几十个方法都要复制粘贴一遍。更可怕的是，有一天日志格式要改，你得把几十个方法全部改一遍，漏一个就是事故。

AOP 就是把这种“横切关注点”从业务方法里抽出来。所谓横切，是指它横着切过了所有业务方法，每个方法执行前、执行后、抛出异常时，都可以插入一段统一逻辑。日志、事务、权限校验、异常统计、性能监控、缓存、限流、审计，这些都属于典型的横切关注点。

相比之下，OOP（面向对象编程）解决的是纵向的模块划分，把系统按业务拆分成一个个类和对象；AOP 解决的则是横向的、跨模块的公共逻辑。它俩不冲突，是互补的。这也是为什么“AOP 使用场景”一直是面试和实际项目里的高频问题——因为只要是个像样的业务系统，几乎都离不开它。

1.2 为什么 Spring 生态离不开 AOP

Spring 把 AOP 的地位抬到了一个非常高的位置，甚至可以说Spring 里很多核心功能就是 AOP 的直接产物。

最典型的就是@Transactional事务管理。你写一个@Transactional注解，Spring 并不靠魔法来实现事务，它是在运行时给目标 Bean 生成一个代理对象，代理对象在方法执行前开启事务，方法正常返回时提交事务，方法抛出异常时回滚事务。这些逻辑全在代理里，你的业务代码本身完全感知不到。这就是声明式事务的本质，也是 AOP 在 Spring 里最重量级的一次应用。

Spring Security 的方法级安全控制（@PreAuthorize、@Secured）同样是基于 AOP 的。当你在方法上标注权限表达式，Spring Security 的拦截器会先于业务代码检查当前用户是否具备权限。还有缓存抽象（@Cacheable）、异步执行（@Async）、参数校验（Spring 在 Web 层的@Valid配合MethodValidationPostProcessor）、操作审计、调用链追踪，底层都跑在 AOP 机制上。

换句话说，你在 Spring 里常用的这些声明式注解，表面上是“注解驱动开发”，本质上是“AOP 驱动开发”。理解了这一点，再看 Spring 的源码和面试题，很多困惑会一下子解开。这也是为什么网上到处是 Spring AOP 原理、@Transactional失效分析、Spring 三级缓存原理这类文章——因为它们背后全都牵着 AOP 这条线。

2. Spring AOP 的工作原理，以及容易忽略的细节

2.1 动态代理：JDK 动态代理与 CGLIB

Spring AOP 不是靠修改字节码实现的，它属于运行时动态代理。意思是 Spring 在容器启动阶段，动态生成一个和目标类“长得一样”的代理对象，然后把代理对象交给调用方。你注入进去的 Service，其实十有八九是代理类。

动态代理在 Java 里只有两条路：JDK 动态代理和 CGLIB。

JDK 动态代理要求目标类必须实现一个或多个接口。它通过Proxy.newProxyInstance生成一个实现了这些接口的代理类，所有接口方法的调用都会被转发到InvocationHandler.invoke。因为代理类只认识接口，所以它没有办法代理那些不在接口里定义的方法。

CGLIB 走的是另一条路，它直接在字节码层面生成目标类的子类，然后重写父类的非 final 方法。因为是子类继承，所以目标类可以不实现任何接口，public和protected方法都能被代理。

Spring 早期版本的默认策略是：有接口就用 JDK 动态代理，没有接口才用 CGLIB。但从 Spring Boot 2.x 开始，默认策略改成了强制 CGLIB，即使目标类实现了接口也照样生成子类代理。这个变化很多人没注意，但它带来一个实际影响：CGLIB 生成的代理类是你的目标类的子类，如果你在代码里对代理对象做父类类型强转、反射获取方法等操作，可能拿到的是代理增强后的结果。好在平时业务代码感知不明显，但一旦涉及 AOP 排查，这就是关键线索。

动态代理有两个天然限制，无论如何都绕不开：

• private方法不能被代理。因为代理类根本看不到目标类的私有方法。
• final方法在 CGLIB 下不能被代理，因为子类不能重写 final 方法。JDK 动态代理下，接口里的方法天然不是 final 的，所以这条限制主要砸在 CGLIB 头上。
• static方法也不能被代理，因为静态方法属于类，不属于对象实例。

2.2 AspectJ 注解与自动代理机制

这里必须澄清一个高频误解：Spring AOP 使用的@Aspect、@Around、@Pointcut注解，并不是 AspectJ 框架在运行，只是借用了 AspectJ 的注解定义和切点表达式语法。真正的执行者还是 Spring 自己的动态代理机制。

Spring 里负责把@Aspect切面类和目标 Bean 绑定到一起的，是一个叫做AnnotationAwareAspectJAutoProxyCreator的BeanPostProcessor。每个 Bean 创建完成后，它都会执行postProcessAfterInitialization，判断当前 Bean 是否匹配任何一个切面的切点表达式。匹配上了，就立刻创建代理对象返给容器；匹配不上，就直接返回原始对象。

所以，Spring AOP 的默认工作模式是“全量检查，命中才代理”。容器里几百个 Bean，每个 Bean 初始化完都得过一次切点匹配判断。Spring 做了很多缓存优化，但在 Bean 数量极其庞大、切点表达式又很复杂的项目里，这段启动开销是真实存在的。

切点表达式的功能则来自 AspectJ 的表达式模型。常用的有：

• execution(public * com.example.service.*.*(..))：按方法签名匹配。
• within(com.example.controller..*)：按类所在包匹配。
• @annotation(com.example.annotation.Log)：按方法上的注解匹配。
• bean(userService)：按 Bean 名称匹配。

Spring AOP 支持五种通知类型：@Before（前置）、@After（后置，无论是否异常都执行）、@AfterReturning（正常返回后）、@AfterThrowing（抛出异常后）、@Around（环绕，最强大，可以自定义整个调用流程）。日常开发里用@Around最多，因为它一个注解就能覆盖另外四种的大部分需求。

2.3 Spring AOP 与三级缓存、循环依赖的隐秘关系

聊 Spring AOP 绕不开 Spring 三级缓存，因为循环依赖和 AOP 代理之间有一个非常容易踩坑的交互点。

三级缓存是 Spring 解决单例 Bean 循环依赖问题的三段缓存，核心思路是：A 依赖 B、B 依赖 A 时，A 可以先把自己早期的对象引用放进三级缓存并暴露给 B，让 B 先建完，然后 A 再继续完成自己的初始化。三级缓存中前两级存对象，第三级存的是一个ObjectFactory工厂。

这个工厂里有一个关键方法叫getEarlyBeanReference。当某个 Bean 处于循环依赖中、且它同时命中了 AOP 切点时，Spring 必须在这一步就判断是否要提前创建代理对象。原因不难理解：B 手里拿到的 A 如果是原始对象而没有提前被代理，那么 A 上应该生效的切面逻辑（比如事务、日志）在 B 的调用链里就全部失效了。

但如果没有循环依赖，AOP 代理是在 Bean 初始化完成之后，由AutoProxyCreator在postProcessAfterInitialization阶段生成的。这两种情况生成的代理时机不一样，导致同一个 Bean 在不同场景下可能是“正常代理”或“提前代理”，排查时非常容易困惑。

所以面试题里常把“Spring 三级缓存原理”和“AOP 代理”放在一起考，本质就是在考你有没有真正理解代理对象生成时机和循环依赖暴露引用的先后关系。你的代码如果出现 AOP 不生效，先别急着怀疑切点表达式，想想是不是 Bean 在循环依赖中被提前暴露了、切面有没有覆盖到这个早期引用，这个排查方向往往更有效。

3. 轻量与精准：Solon AOP 做了什么不一样的事

3.1 Solon 的设计哲学：能不代理就不代理

Solon 是一个明显不同于 Spring 的国产 Java 应用框架。它的核心定位是轻量、快速启动、低内存占用，面向云原生、嵌入式、网关这类对资源敏感的 Java 场景。Solon 官方一直强调自己启动速度比 Spring Boot 快数倍，内存占用大幅降低，其中一个关键设计就是从框架层面“尽力避免不必要的开销”。

这套理念直接渗透进了它的 AOP 设计。Solon AOP 的核心哲学可以概括成一句话：显式开启，才做代理。

在 Spring 里，只要容器中存在切面定义，AutoProxyCreator就会对容器内所有 Bean 逐一检查是否命中切点，不管你愿不愿意，这套检查开销都会发生。而 Solon 采用了完全相反的思路：普通组件默认不生成代理，只有当你明确告诉容器“这个组件需要被 AOP 支持”时，容器才会为它创建代理对象。这个标记就是@ProxyComponent。

换句话说，Spring 的默认行为是“所有 Bean 都可能被代理”，Solon 的默认行为是“默认都不代理，谁需要使用谁声明”。这个差异在业务代码量小的时候感受不明显，但在一个成百上千个 Bean 的大型服务里，Solon 省掉的就是那一大轮“全局切点匹配 + 代理生成判断”的启动开销。这也是 Solon 启动更快的底因之一。

@ProxyComponent在 Solon 里的地位有点像@Component的“可代理版本”。如果你在 Solon 里写了一个普通@Component，然后在它上面声明切面，会发现拦截根本不会触发，改回@ProxyComponent之后立刻生效。这个坑我身边不止一个人踩过，它是 Solon AOP 最典型的一个入门陷阱。

3.2 Solon AOP 的两种典型用法

Solon 的 AOP 用法和 Spring 有点像，但 API 更“短平快”。如果你用的是新版本 Solon，最直接的方式是引入solon-aspect扩展，然后像写 Spring AOP 一样写一个切面类。

@Aspect public class LogAspect { @Around public Object around(Invocation inv) throws Throwable { long start = System.currentTimeMillis(); try { return inv.invoke(); } finally { System.err.println("method cost: " + (System.currentTimeMillis() - start) + " ms"); } } }

这里Invocation是 Solon 对方法调用的一个封装，类似 Spring 里的ProceedingJoinPoint。inv.invoke()等价于pjp.proceed()。@Aspect声明这是一个切面，@Around声明环绕逻辑，整体结构对 Spring 用户来说几乎零成本迁移。

不过，不同 Solon 版本之间 AOP API 演进比较快，有的版本用@Aspect注解绑定类，有的版本推荐直接通过AopContext注册拦截器。所以在写代码之前，建议先翻一下你所用版本对应的官方文档，不要拿 2.x 老版本的写法直接套到新版上。

另一种更偏 Solon 原生风格的做法，是通过自定义注解 + 拦截器注册来绑定切面逻辑。首先定义一个注解：

@Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE, ElementType.METHOD}) public @interface Metrics { }

然后在目标方法上使用这个注解：

@ProxyComponent public class HelloService { @Metrics public String hello(String name) { return "Hello " + name; } }

接着实现 Solon 的Interceptor接口，并在应用启动时注册：

public class MetricsInterceptor implements Interceptor { @Override public Object doIntercept(Invocation inv) throws Throwable { long start = System.currentTimeMillis(); Object result = inv.invoke(); System.out.println("hello cost: " + (System.currentTimeMillis() - start) + " ms"); return result; } }

public class DemoApp { public static void main(String[] args) { Solon.start(DemoApp.class, args); AopContext context = Solon.context().getAopContext(); context.beanInterceptorAdd(Metrics.class, new MetricsInterceptor()); } }

这种方式的好处是切面和业务完全解耦，你不需要在切面里写一串复杂表达式，只需要通过“注解类型”这个约定，就能把拦截器和目标方法绑定起来。对很多真实项目来说，“按注解拦截”已经覆盖了大多数场景，日志、限流、幂等等都可以这么设计。

3.3 Solon AOP 的能力边界

既然 Solon AOP 主打轻量，那它和 Spring AOP 的能力差距到底在哪？最核心的一点是切点表达式的表达能力。

Spring AOP 背后有 AspectJ 那一整套切点表达式模型，execution、within、target、args、@annotation可以自由组合，可以用&&、||、!做逻辑运算。这意味着 Spring 可以用一句话精确描述“我要拦截controller包下所有以Page结尾的类的所有public方法，但排除带有@SkipLog注解的方法”。这种表达能力是 Solon 原生 AOP 目前不具备的。

Solon 的 AOP 更偏向“按注解绑定”和“按类/包名简单匹配”，它能覆盖日常开发中 80% 以上的日志、事务、鉴权、限流需求，但如果你需要非常细粒度的跨包规则、复杂的多切面组合表达式，Solon 用起来会明显感觉“不够写”。

还有一点是通知类型。Spring AOP 有五种通知类型，Solon 官方主推的其实是环绕式拦截，其他类型的语义一般通过@Around自行控制。这种设计确实更简单，但也意味着如果你习惯用@AfterReturning单独处理返回值、用@AfterThrowing单独处理异常，迁到 Solon 时需要改成在一个环绕方法里通过判断实现。

这也引出一个很重要的选型维度：框架 AOP 的边界，决定了你能在上面盖多复杂的房子。如果你只是需要一个轻量服务，Solon 的简单反而更合适；如果业务层有大量跨模块的横切规则，Spring 的成熟度是实打实的优势。

4. Spring AOP 与 Solon AOP 的核心区别对比

4.1 代理机制层面：全量匹配 vs 显式标记

把两者的底层机制放在一起看，差异非常清晰。

Spring AOP 的“全量检查”机制可以理解成一个严格的门禁系统。容器里每个 Bean 建好之后，都必须经过安检闸门，自动代理创建器拿着所有切面规则一个一个比对，命中哪一个就按哪个规则生成代理。这个机制的优点是自动化程度高，容器自动完成一切；缺点是所有 Bean 都要过一遍匹配逻辑，即使最后并没有为它创建代理。

Solon AOP 的“显式标记”机制更像 VIP 预约通道。容器只对明确标注了“需要代理”的组件（例如@ProxyComponent）做额外处理，其他组件直通放行。这样确实大幅减少了没必要的代理判断，但也把责任转交给了开发者：你忘了加标记，切面就不生效，而且不会报错，只会静默失效。

这两种设计没有绝对的对错。Spring 把复杂度集中到框架内部，让业务开发更省心；Solon 把复杂度留给开发者，换取启动阶段更低的资源消耗。

4.2 开发体验层面：API 丰富度与学习成本

从开发体验来说，Spring AOP 的生态成熟、资料多，遇到问题随便一搜都是现成方案。@Aspect、@Around、@Pointcut这一套早已是 Java 开发者的公共知识，新员工入职几乎不需要额外培训。

Solon AOP 的优势是上手路径更短。你用@Aspect写一个类，用@Around写一个方法，再调一下inv.invoke()，切面就生效了。没有复杂的切点表达式语言要学，也没有Advisor、Advice这一大堆概念要理。对一个小团队来说，这个学习成本差距是实实在在的。

但甘蔗没有两头甜。Solon AOP 的 API 演进速度偏快，不同版本之间可能存在写法差异，官方文档和社区资料也没有 Spring 那么厚。遇到一些偏门问题，你可能要把源码翻出来自己看。这一点在选型时一定要考虑进去，尤其是团队规模大、人员流动频繁的时候。

4.3 性能与生态层面：启动开销和社区支持

性能上，Solon 设计目标就是轻，它的 AOP 由于少了全局切点匹配这一层，启动阶段确实可以更省。单次代理方法调用的开销两者本质上没有数量级的差别，因为底层都是动态代理 + 反射或字节码方法的调用。真正拉开差距的是大批量 Bean 创建场景下的启动时间，这也正是 Solon 让人眼前一亮的地方。

不过我建议，不要单纯因为启动时间快就决定迁移。把 Spring Cloud、Spring Security、MyBatis、Nacos 这些全家桶换成 Solon 生态的对应组件，整套系统的改造工作量会非常大。启动速度快那几百毫秒，可能在迁移成本面前不值一提。除非你是新项目起步，或者明确要做一个资源受限的轻量服务。

生态方面，Spring 的优势不用多说，spring-boot-starter-*几乎所有中间件都有现成 starter。Solon 也有自己的生态，覆盖了常见中间件，但成熟度、社区人数、第三方集成丰富度都和 Spring 有差距。做技术选型不能只看 AOP 本身，要看整个技术栈的支撑能力。

4.4 一张表格看完整区别

这张表基本把两者的骨相画清楚了。不过我要多提醒一句：能力边界不等于实际需要。90% 的项目真正用到的 AOP 能力就那么几种，能不能用“完整 AspectJ 表达式”，在实际工作中未必是决定成败的因素。

5. 实操参考：同一个日志切面，两种落地方式

5.1 Spring AOP 项目实操：五步搭好日志切面

第一步，引入依赖。Spring Boot 项目只需要一个 starter：

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

第二步，建一个切面类，标注@Aspect和@Component：

@Aspect @Component public class MethodLogAspect { // 切点：拦截 service 包下所有类的所有方法 @Pointcut("execution(* com.example.service.*.*(..))") public void servicePointcut() { } @Around("servicePointcut()") public Object logAround(ProceedingJoinPoint pjp) throws Throwable { long start = System.currentTimeMillis(); Object result = pjp.proceed(); System.out.printf("[%s] executed in %d ms%n", pjp.getSignature().toShortString(), System.currentTimeMillis() - start); return result; } }

第三步，写一个业务 Service 来验证：

@Service public class UserService { public String getUsername(Long id) { return "user-" + id; } }

第四步，写个简单的调用入口。正常从 Spring 容器里取出UserService，调用getUsername，然后看控制台输出，会发现日志已经打印出来了。

第五步，如果要让AopContext.currentProxy()可用，需要开启暴露代理：

spring: aop: expose-proxy: true

或者使用@EnableAspectJAutoProxy(exposeProxy = true)。这个功能在自调用场景下会用到，平时不必开启。

这套流程在 Spring Boot 里几乎任何项目都能跑通。注意一下@Pointcut表达式的范围，务必精确到具体包，不要一上来就写execution(* *..*(..))这种拦全项目的超大范围，否则启动时那一轮切点匹配会让所有 Bean 都增加不必要的负担。

5.2 Solon AOP 项目实操：注解绑定一次搞定

Solon 项目的核心依赖需要solon，做 AOP 再引入solon-aspect（具体坐标以你使用的 Solon 版本对应文档为准）：

<dependency> <groupId>org.noear</groupId> <artifactId>solon-aspect</artifactId> </dependency>

然后写一个切面类，结构与 Spring 非常接近：

@Aspect public class MetricsAspect { @Around public Object around(Invocation inv) throws Throwable { long start = System.currentTimeMillis(); try { return inv.invoke(); } finally { System.out.println("cost: " + (System.currentTimeMillis() - start) + " ms"); } } }

写一个需要被代理的组件。前面强调过，@ProxyComponent是关键，换成普通@Component可能不会生效：

@ProxyComponent public class HelloService { public String hello(String name) { return "hello " + name; } }

如果你的版本支持直接对字符串形式的切点做绑定，也可以在切面里用类似@Around("com.example.service..*")的写法指定范围。如果只支持注解绑定，那就用自定义注解作为切点标记，通过AopContext注册拦截器，写法我在 3.2 小节已经给出。

Solon 这里我要强调一点：不同版本的 Solon AOP 代码差异可能比你想象的更大。比如某个版本里拦截器接口叫Interceptor，另一个版本可能改成了函数式接口或者换成了@Aspect注解体系。我在写这篇时给出的写法适用于当前常见版本，但你在实操时一定要以所用版本对应文档为准。这不算缺点，但它是 Solon 用户必须接受的“版本演进成本”。

5.3 实际测试的感受：启动和调用的差异

我在同一台机器上分别用 Spring Boot 和 Solon 跑过带日志切面的最小工程，直观感受是 Solon 的启动确实明显更快，内存占用也更小。不过这里我必须说明，具体数值和你的 Bean 数量、机器配置、JDK 版本强相关，我不贴数据，建议你自己动手测，用自家业务场景来验证。

运行期的单次方法调用开销，两者实际体感几乎没有差别。AOP 调用链路都是“业务代码 → 代理对象 → 切面方法 → 目标方法”，一次额外的方法栈跳转损耗都在微秒级别，除非你是在高频调用点做极端性能调优，否则不用纠结这一层。

代码可读性上，Spring AOP 的复杂表达式虽然强大，但也提高了理解门槛；Solon 的“显式标记 + 注解绑定”更平铺直叙，新人看代码能直接明白“哪些方法是带切面的”。对小型团队来说，这种直观性很有价值。

6. 常见问题与避坑实录

6.1 this 自调用导致切面不生效

这是 Spring AOP 排障榜第一名：你在同一个类里写了一个带@Transactional的方法，然后在另一个方法里直接this.xxx()调用它，结果事务没生效。原因前面讲过，this指向的是原始对象而不是代理对象，切面逻辑全在代理里，原始对象内部的方法调用自然不会经过代理。

解除办法有三类：

• 把需要被切面拦截的方法拆到一个独立 Bean 里，由外部调用方注入并调用它。这是最干净、最推荐的做法。
• 在 Spring 中开启exposeProxy，然后使用((UserService) AopContext.currentProxy()).method()强制走代理。
• 在 Solon 中同理，任何在目标对象内部绕过代理的直调都不会触发拦截器。最佳实践同样是独立拆分，不要依赖代理对象自引用。

记住一个通用判断标准：AOP 拦截的是“代理对象”的方法调用，而不是“目标对象”的方法执行。只要调用发生在代理对象之外，切面才会生效。

6.2 final 方法、private 方法与代理方式的坑

CGLIB 靠继承生成代理，所以 final 方法无法被重写，自然无法拦截。这影响了很多人的“最终类 + 模板方法”设计，比如你给某个 Service 类加了final修饰，或者把某个方法定义成final，AOP 对它就失效了。Spring Boot 2.x 之后默认用 CGLIB，平时写代码要留意这一点。

private 方法则是无论 JDK 动态代理还是 CGLIB 都拦不住，这个是 Java 语言层面的访问限制，任何框架都绕不过去。如果你发现某些私有方法的公共逻辑没有被统一拦截，不要惊讶，先看看它是不是private。当然，实际项目中很少有人会对 private 方法做切面，但排查时不排除这个原因，容易白费力气。

另外，判断一个对象是否有代理，我常用的办法是在代码里打印它的真实类名：

System.out.println(userService.getClass());

如果输出里带CGLIB、$$、Proxy这类字样，说明你拿到的是代理对象。这个方法在调试时非常实用，一眼就能看出 Spring 或 Solon 是否真的为这个 Bean 生成了代理。

6.3 多个切面的执行顺序：@Order 怎么用

业务系统里往往不止一个切面。比如日志切面和事务切面同时作用在一个方法上，日志要包在事务外面，还是事务包在日志外面？这就要靠切面排序来控制。

Spring 里的通用做法是给切面类标注@Order，或者实现Ordered接口。数值越小，优先级越高，外层环绕越靠前。比如@Order(1)的日志切面会先执行，@Order(10)的事务切面在其内部再执行，这样日志就把事务的耗时也统计进去了。

Solon 的排序规则在不同版本里略有差异，有的按注册顺序，有的也支持注解排序。实操时我建议先做一个最小验证再依赖它，不要凭经验默认两边行为完全一致。这里有一个经验分享：切面排序不要依赖“隐式顺序”，任何团队都应该在文档里明确规定常用切面的 Order 档位约定。比如 0-100 留给基础组件、100-200 留给业务日志，避免不同模块乱写 Order 导致互相覆盖。

6.4 循环依赖场景下 AOP 代理的“提前”问题

我在 2.3 节讨论过三级缓存。实际项目里因为循环依赖导致的 AOP 问题不太容易复现，因为它通常发生在多个 Bean 互相引用且部分 Bean 带切面的场景。

典型表现为：某个 Bean 通过循环依赖被提前暴露，切面没有生效或只生效了一半。排查方法很直接，先判断这个 Bean 是否处于循环依赖链路上，再检查切面到底是“初始化后代理”还是“提前代理”。

Solon 的应对策略更简单：框架不默认支持单例循环依赖，设计层面就建议大家不要写循环引用。这不是功能缺失，而是明确的设计取舍：Spring 花了很大复杂度处理历史遗留的循环依赖问题，Solon 选择把复杂度挡在门外，鼓励开发者写出更清晰的依赖关系。我在实践里很认同这个取向，很多循环依赖本身就是因为服务拆分不合理导致的，与其解决它，不如重构掉它。

6.5 表达式写太宽，全项目启动明显变慢

Spring AOP 里有个特别容易犯的毛病：切点表达式写得特别宽，比如execution(* *..*(..))，意图是“拦截所有方法”。结果就是容器里每个 Bean 初始化时都要做一轮全量匹配，加上缓存也没能完全抵消开销，项目启动时间肉眼可见地变长。

正确的做法是尽量精确缩小范围。能用包名限定就限定到包，能用注解限定就用注解。比如用@annotation(com.example.annotation.Log)来替代“所有方法”这种粗放写法，切面的作用域清晰，排查问题也更方便。

Solon AOP 因为本身就走显式标记路线，几乎没有这种“全量匹配”的启动损耗，但这不代表它没有性能意识。你依然应该控制好切面数量和拦截范围，避免一个超大注解被挂在几十个类的每个方法上。

7. 选型建议

7.1 什么场景建议用 Spring AOP

如果你的项目已经是 Spring Boot 或者 Spring Cloud 体系，我不建议仅仅因为 AOP 细节就换框架，Spring AOP 是这套体系里最成熟的一环。团队规模越大，越需要标准化、文档齐全、社区成熟的方案，AspectJ 切点表达式的复杂规则虽然难一点，但它能覆盖各种边界需求。

需要复杂事务边界、方法级安全、分布式调用链追踪、动态数据源切库逻辑的系统，Spring AOP 依然是首选。它的成熟度和生态深度，决定了你在踩坑时可以快速找到答案，而这一点在团队协作里非常值钱。

7.2 什么场景建议用 Solon AOP

如果你是新建项目，尤其是一个资源受限的微服务、边缘计算节点、嵌入式 Java 服务，或者一个启动内存被严格约束的云原生网关，Solon 非常值得认真考虑。它的启动速度快、内存占用低、依赖轻，AOP 设计也足够满足日志、耗时、限流、简单事务这类日常需求。

如果团队里已经有熟练使用 Solon 的人，或者项目本身就在做国产化适配，Solon AOP 的简洁性会让维护成本进一步降低。我建议在选型时跑一个带 AOP 的最小可运行 Demo，亲眼看一看启动时间和内存数据，再决定是否值得迁移。

7.3 我的个人体会

两套框架的 AOP 不是同一维度的竞争关系。Spring AOP 是“重工重料”的完备方案，Solon AOP 是“轻装简行”的高性价比方案，两者解决的核心问题相同，但取舍逻辑完全不同。

就我个人经验而言，Solon AOP 最打动我的点是它把“代理”这个事变得很透明：你要代理，就明说，没有那么多隐式规则。这种风格让代码更容易维护，但也对团队的自律性提出了更高要求——忘了标记就会静默失效，没有全局自动代理帮你兜底。

把这个对比扩展到你整个技术栈的选型上，我会建议你关注的不只是 AOP 本身，而是框架背后的一整套生态和设计哲学。AOP 只是冰山一角，真正决定项目长期体验的，是你选择的框架与你的团队能力、项目约束是否匹配。