Spring AOP 是 Spring 框架的核心特性之一，通过面向切面编程实现业务逻辑与通用功能的解耦。本文深入解析了 Spring AOP 的底层原理，重点对比了 JDK 动态代理与 CGLib 动态代理的实现机制。内容涵盖 AOP 核心概念如切面、通知、切入点等，详细演示了手写日志代理的实战代码，分析了两种代理方式的适用场景与性能差异。同时梳理了 Spring AOP 从初始化到方法调用的完整执行流程，并结合 Spring Boot 注解提供了完整的配置案例。最后总结了代理选择策略及性能优化建议，为开发者提供全面的技术指南。
在 Spring 框架的核心特性中，AOP（面向切面编程）无疑是与 IOC（控制反转）并驾齐驱的灵魂技术。它通过"横切"的方式，将日志记录、事务管理、权限控制等分散在业务逻辑中的通用功能抽取出来，形成独立的切面，实现了"业务功能"与"通用功能"的解耦，极大提升了代码的复用性和可维护性。而支撑 Spring AOP 实现的核心技术，正是动态代理——其中 JDK 动态代理与 CGLib 动态代理更是重中之重。本文将从 AOP 的基础概念出发，层层深入剖析这两种动态代理的实现原理、代码细节及适用场景，最终梳理 Spring AOP 的整体执行逻辑，为开发者提供一份全面且实用的技术指南。
在传统的 OOP（面向对象编程）开发中，我们习惯于将功能封装在类和对象中，通过继承和多态实现代码复用。但在实际业务场景中，会存在一些"跨界"的通用功能，例如：
这些代码与核心业务逻辑无关，却分散在各个业务类中，导致代码冗余、维护成本高——修改日志格式需要改动所有日志相关代码，调整事务隔离级别则要遍历所有事务方法。AOP 的出现正是为了解决这一问题，它将这些通用功能抽象为"切面"，在不修改业务代码的前提下，通过"织入"机制将切面与业务逻辑结合，实现通用功能的统一管理。
要理解 Spring AOP 的实现原理，首先需要掌握其核心概念，这些概念共同构成了 AOP 的"语言体系"，也是后续理解动态代理的基础：
切面是 AOP 的核心载体，它封装了需要横切到业务逻辑中的通用功能，例如"日志切面"、"事务切面"。在 Spring 中，切面通常是一个带有@Aspect 注解的类，其中包含了通知和切入点的定义。
通知定义了切面的具体执行逻辑和执行时机，即"在什么时候做什么事"。Spring 支持 5 种类型的通知：
切入点定义了切面的"作用范围"，即"对哪些方法生效"。它通过切入点表达式（如 execution 表达式）指定目标方法，例如"所有 com.example.service 包下以 find 开头的 public 方法"。切入点是连接切面与目标对象的桥梁，只有匹配切入点的方法才会被织入通知逻辑。
目标对象即被切面织入的业务对象，也就是包含核心业务逻辑的对象，例如 UserService、OrderService 等。
代理对象是 Spring AOP 实现的关键——Spring 不会直接修改目标对象的代码，而是通过动态代理技术为目标对象创建一个代理对象。当客户端调用目标方法时，实际上是调用代理对象的方法，代理对象会在合适的时机执行切面的通知逻辑，再调用目标对象的原始方法。
织入是将切面的通知逻辑融入到目标对象业务方法中的过程。根据织入时机的不同，可分为编译期织入（如 AspectJ）、类加载期织入和运行期织入——Spring AOP 采用的是运行期织入，通过动态代理在程序运行时动态生成代理对象，完成通知与目标方法的结合。
Spring AOP 的核心逻辑可概括为"代理介导"：客户端请求目标对象时，Spring 的 IOC 容器返回的不是目标对象本身，而是其代理对象；客户端调用代理对象的方法时，代理对象先执行切面的通知逻辑（如日志记录、权限校验），再调用目标对象的原始方法；方法执行完成后，代理对象还会执行后续的通知逻辑（如事务提交、返回值处理）。整个过程中，客户端无需感知代理对象的存在，目标对象的业务代码也无需修改，从而实现了通用功能与业务逻辑的解耦。
JDK 动态代理是 Spring AOP 默认使用的代理方式，它基于 Java 的反射机制实现，核心依赖 java.lang.reflect 包下的 Proxy 类和 InvocationHandler 接口。需要注意的是，JDK 动态代理有一个重要限制：只能为实现了接口的目标对象创建代理对象，这是由其底层实现机制决定的。
要理解 JDK 动态代理，首先需要掌握其两个核心组件的作用，它们共同支撑起代理对象的创建和逻辑执行：
InvocationHandler 是一个函数式接口，仅包含一个 invoke 方法，它是代理对象的"逻辑处理器"——当客户端调用代理对象的方法时，最终都会委托给该接口的 invoke 方法执行。其定义如下：
public interface InvocationHandler {
/**
* 代理对象方法调用的核心处理方法
* @param proxy 代理对象本身
* @param method 被调用的目标方法
* @param args 目标方法的参数数组
* @return 目标方法的返回值
* @throws Throwable 目标方法可能抛出的异常
*/
Object invoke(Object proxy, Method method, Object[] args) throws Throwable;
}
invoke 方法的三个参数含义明确：proxy 是动态生成的代理对象；method 是客户端调用的目标方法实例，通过它可以反射调用目标对象的方法；args 是客户端传递给目标方法的参数。开发者需要在 invoke 方法中实现"通知逻辑 + 目标方法调用"的组合逻辑。
Proxy 类是 JDK 动态代理的"代理工厂"，它提供了静态方法 newProxyInstance 用于创建代理对象。该方法是 JDK 动态代理的入口，其定义如下：
public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException
三个参数的作用至关重要，直接决定了代理对象的生成：
理论结合实践是理解技术的最佳方式，下面我们通过一个"日志切面"的案例，手写 JDK 动态代理的完整实现，直观感受其工作流程。
由于 JDK 动态代理依赖接口，首先定义一个业务接口 UserService，包含用户查询和新增两个方法，再创建其实现类 UserServiceImpl 作为目标对象：
// 目标接口
public interface UserService {
// 查询用户
User findUserById(Long id);
// 新增用户
void addUser(User user);
}
// 目标对象（业务实现类）
public class UserServiceImpl implements UserService {
@Override
public User findUserById(Long id) {
// 模拟数据库查询
System.out.println("执行数据库查询：根据 ID=" + id + "查询用户");
return new User(id, "张三", 25);
}
@Override
public void addUser(User user) {
// 模拟数据库新增
System.out.println("执行数据库新增：添加用户" + user.getName());
}
}
// 实体类 User
public class User {
private Long id;
private String name;
private Integer age;
// 构造方法、getter、setter 省略
}
创建 LogInvocationHandler 类实现 InvocationHandler 接口，在 invoke 方法中实现"前置日志 + 目标方法调用 + 后置日志"的逻辑，这就是我们的"日志切面"：
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.time.LocalDateTime;
public class LogInvocationHandler implements InvocationHandler {
// 目标对象（被代理的业务对象）
private Object target;
// 构造方法注入目标对象
public LogInvocationHandler(Object target) {
this.target = target;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// 1. 前置通知：日志记录（方法调用时间、方法名）
String methodName = method.getName();
System.out.println("【日志前置通知】" + LocalDateTime.now() + " 调用方法：" + methodName);
// 2. 调用目标对象的原始方法
Object result = null;
try {
result = method.invoke(target, args);
// 3. 返回通知：记录方法返回值
System.out.println("【日志返回通知】方法" + methodName + "返回值：" + (result == null ? "无" : result.toString()));
} catch (Exception e) {
// 4. 异常通知：记录方法异常信息
System.out.println("【日志异常通知】方法" + methodName + "抛出异常：" + e.getMessage());
throw e; // 抛出异常，不影响业务逻辑
} finally {
// 5. 后置通知：记录方法调用结束
System.out.println("【日志后置通知】方法" + methodName + "调用结束\n");
}
return result;
}
}
创建测试类，通过 Proxy.newProxyInstance 方法生成代理对象，然后调用代理对象的方法，观察日志切面是否生效：
import java.lang.reflect.Proxy;
public class JdkProxyTest {
public static void main(String[] args) {
// 1. 创建目标对象
UserService target = new UserServiceImpl();
// 2. 创建 InvocationHandler 实例（传入目标对象）
LogInvocationHandler invocationHandler = new LogInvocationHandler(target);
// 3. 生成代理对象：参数分别为目标类加载器、目标接口数组、InvocationHandler
UserService proxy = (UserService) Proxy.newProxyInstance(
target.getClass().getClassLoader(),
target.getClass().getInterfaces(),
invocationHandler
);
// 4. 调用代理对象的方法
proxy.findUserById(1L);
proxy.addUser(new User(2L, "李四", 30));
}
}
运行测试类，输出结果如下：
【日志前置通知】2025-12-05T15:30:00 调用方法：findUserById 执行数据库查询：根据 ID=1 查询用户 【日志返回通知】方法 findUserById 返回值：User(id=1, name=张三，age=25) 【日志后置通知】方法 findUserById 调用结束 【日志前置通知】2025-12-05T15:30:00 调用方法：addUser 执行数据库新增：添加用户李四 【日志返回通知】方法 addUser 返回值：无 【日志后置通知】方法 addUser 调用结束
从结果可以看出，代理对象成功将日志通知逻辑与业务方法结合：调用 findUserById 和 addUser 方法时，均先执行前置日志，再执行核心业务逻辑，最后执行返回通知和后置通知。这正是 JDK 动态代理的核心作用——通过代理对象介导，实现切面逻辑与业务逻辑的解耦。
很多开发者会好奇：Proxy.newProxyInstance 方法调用后，代理对象的字节码是如何生成的？其实，JDK 动态代理的底层是通过"动态生成字节码文件"并加载到 JVM 中实现的，具体流程如下：
我们可以通过设置系统属性，将 JDK 动态生成的代理类字节码保存到本地，以便直观查看。在测试类的 main 方法开头添加如下代码：
// 保存 JDK 动态生成的代理类字节码到本地
System.getProperties().put("sun.misc.ProxyGenerator.saveGeneratedFiles", "true");
运行后，会在项目根目录下生成 com/sun/proxy/$Proxy0.class 文件，反编译后可以看到代理类的核心结构（简化后）：
public final class $Proxy0 extends Proxy implements UserService {
// 静态代码块：获取目标接口的方法实例
static {
try {
m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
m2 = Class.forName("java.lang.Object").getMethod("toString");
m3 = Class.forName("com.example.service.UserService").getMethod("findUserById", Class.forName("java.lang.Long"));
m4 = Class.forName("com.example.service.UserService").getMethod("addUser", Class.forName("com.example.entity.User"));
// ...省略其他方法
} catch (NoSuchMethodException e) {
throw new NoSuchMethodError(e.getMessage());
}
}
// 构造方法：接收 InvocationHandler 参数并传给父类 Proxy
public $Proxy0(InvocationHandler var1) throws {
super(var1);
}
// 实现 UserService 的 findUserById 方法
public final User findUserById(Long var1) throws {
try {
// 调用 InvocationHandler 的 invoke 方法
return (User) super.h.invoke(this, m3, new Object[]{var1});
} catch (RuntimeException | Error var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
// 实现 UserService 的 addUser 方法
public final void addUser(User var1) throws {
try {
// 调用 InvocationHandler 的 invoke 方法
super.h.invoke(this, m4, new Object[]{var1});
} catch (RuntimeException | Error var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
}
反编译后的代码清晰地展示了代理类的结构：它继承自 Proxy 类，实现了 UserService 接口，每个接口方法的实现都委托给了 InvocationHandler 的 invoke 方法。这也就解释了为什么调用代理对象的方法会触发 invoke 方法的执行——代理类的方法逻辑就是如此设计的。
上一章我们提到，JDK 动态代理只能为实现了接口的目标对象创建代理，这在实际开发中存在局限性——如果某个业务类没有实现任何接口（如遗留系统中的类），JDK 动态代理就无法满足需求。此时，CGLib 动态代理便成为了 Spring AOP 的补充方案。CGLib（Code Generation Library）是一个基于 ASM 字节码操作框架的代码生成类库，它通过"继承目标类"的方式创建代理对象，无需目标类实现接口。
CGLib 动态代理的核心思想是"继承目标类，重写目标方法"：
需要注意的是，CGLib 无法代理 final 类和 final 方法——因为 final 类不能被继承，final 方法不能被重写，这是 CGLib 的核心限制。
CGLib 动态代理的核心组件主要有两个：MethodInterceptor 接口和 Enhancer 类，它们的作用与 JDK 动态代理的 InvocationHandler 和 Proxy 类类似。
MethodInterceptor 是 CGLib 的"方法拦截器"，类似于 JDK 动态代理的 InvocationHandler，它定义了代理对象方法调用的核心处理逻辑。该接口仅包含一个 intercept 方法：
public interface MethodInterceptor extends Callback {
/**
* 代理对象方法调用的核心处理方法
* @param obj 代理对象
* @param method 被调用的目标方法
* @param args 目标方法的参数数组
* @param proxy MethodProxy 对象，用于调用目标方法（比反射更高效）
* @return 目标方法的返回值
* @throws Throwable 目标方法可能抛出的异常
*/
Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable;
}
与 invoke 方法相比，intercept 方法多了一个 MethodProxy 参数，它是 CGLib 提供的用于调用目标方法的工具类，其效率比通过反射调用 Method 对象更高——因为 MethodProxy 会生成目标方法的快速调用代码，避免了反射的性能开销。
Enhancer 是 CGLib 的"代理生成器"，类似于 JDK 动态代理的 Proxy 类，它负责动态生成目标类的子类（代理类）并创建代理对象。Enhancer 的核心方法包括 setSuperclass（设置目标类，即代理类的父类）、setCallback（设置方法拦截器）、create（生成并返回代理对象）。
下面我们以一个无接口的业务类为例，实现 CGLib 动态代理的日志切面，对比与 JDK 动态代理的差异。
Spring Boot 项目中已默认引入 CGLib 依赖（通过 spring-core 间接依赖），非 Spring 项目需手动引入：
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>3.3.0</version>
</dependency>
创建一个未实现任何接口的业务类 OrderService，作为 CGLib 的代理目标：
// 无接口的目标对象
public class OrderService {
// 订单查询方法
public Order findOrderById(Long id) {
System.out.println("执行数据库查询：根据 ID=" + id + "查询订单");
return new Order(id, "20251205001", 199.9);
}
// 订单创建方法
public void createOrder(Order order) {
System.out.println("执行数据库新增：创建订单" + order.getOrderNo());
// 模拟异常场景
// if (order.getAmount() < 0) {
// throw new IllegalArgumentException("订单金额不能为负数");
// }
}
}
// 实体类 Order
public class Order {
private Long id;
private String orderNo;
private Double amount;
// 构造方法、getter、setter 省略
}
创建 LogMethodInterceptor 类实现 MethodInterceptor 接口，在 intercept 方法中实现日志通知逻辑：
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
import java.lang.reflect.Method;
import java.time.LocalDateTime;
public class LogMethodInterceptor implements MethodInterceptor {
@Override
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
// 1. 前置通知：日志记录
String methodName = method.getName();
System.out.println("【CGLib 日志前置通知】" + LocalDateTime.now() + " 调用方法：" + methodName);
// 2. 调用目标对象的原始方法（通过 MethodProxy 调用，效率更高）
Object result = null;
try {
result = proxy.invokeSuper(obj, args); // 注意：此处是 invokeSuper，调用父类（目标类）的方法
// 3. 返回通知
System.out.println("【CGLib 日志返回通知】方法" + methodName + "返回值：" + (result == null ? "无" : result.toString()));
} catch (Exception e) {
// 4. 异常通知
System.out.println("【CGLib 日志异常通知】方法" + methodName + "抛出异常：" + e.getMessage());
throw e;
} finally {
// 5. 后置通知
System.out.println("【CGLib 日志后置通知】方法" + methodName + "调用结束\n");
}
return result;
}
}
需要特别注意的是，调用目标方法时使用的是 MethodProxy 的 invokeSuper 方法，而非 invoke 方法：
创建测试类，通过 Enhancer 生成代理对象并调用方法：
import net.sf.cglib.proxy.Enhancer;
public class CglibProxyTest {
public static void main(String[] args) {
// 1. 创建目标对象
OrderService target = new OrderService();
// 2. 创建方法拦截器实例
LogMethodInterceptor interceptor = new LogMethodInterceptor();
// 3. 创建 Enhancer 对象（代理生成器）
Enhancer enhancer = new Enhancer();
// 设置目标类为父类（代理类继承自目标类）
enhancer.setSuperclass(OrderService.class);
// 设置方法拦截器（代理类的方法调用会委托给该拦截器）
enhancer.setCallback(interceptor);
// 4. 生成代理对象（通过 create 方法）
OrderService proxy = (OrderService) enhancer.create();
// 5. 调用代理对象的方法
proxy.findOrderById(1L);
proxy.createOrder(new Order(2L, "20251205002", 299.9));
// 测试异常场景（解开 OrderService 中 createOrder 的异常注释）
// proxy.createOrder(new Order(3L, "20251205003", -50.0));
}
}
运行测试类，输出结果如下：
【CGLib 日志前置通知】2025-12-05T16:00:00 调用方法：findOrderById 执行数据库查询：根据 ID=1 查询订单 【CGLib 日志返回通知】方法 findOrderById 返回值：Order(id=1, orderNo=20251205001, amount=199.9) 【CGLib 日志后置通知】方法 findOrderById 调用结束 【CGLib 日志前置通知】2025-12-05T16:00:00 调用方法：createOrder 执行数据库新增：创建订单 20251205002 【CGLib 日志返回通知】方法 createOrder 返回值：无 【CGLib 日志后置通知】方法 createOrder 调用结束
结果表明，CGLib 成功为无接口的 OrderService 创建了代理对象，日志通知逻辑与业务逻辑完美结合。若解开 OrderService 中 createOrder 方法的异常注释，调用时会触发异常通知，输出如下：
【CGLib 日志前置通知】2025-12-05T16:00:00 调用方法：createOrder 执行数据库新增：创建订单 20251205003 【CGLib 日志异常通知】方法 createOrder 抛出异常：订单金额不能为负数 【CGLib 日志后置通知】方法 createOrder 调用结束 Exception in thread "main" java.lang.IllegalArgumentException: 订单金额不能为负数 ...省略堆栈信息
这说明 CGLib 的异常处理逻辑同样生效，与 JDK 动态代理的通知类型覆盖能力一致。
与 JDK 动态代理类似，CGLib 也是通过动态生成字节码文件来创建代理类的，但其生成逻辑基于 ASM 框架，直接操作字节码，过程更为复杂，核心流程如下：
我们可以通过设置系统属性，将 CGLib 生成的代理类字节码保存到本地。在测试类 main 方法开头添加如下代码：
// 保存 CGLib 生成的代理类字节码到本地
System.setProperty("cglib.debugLocation", "D:/cglib_proxy");
System.setProperty("cglib.generateSpringCglibProxyClass", "true");
运行后，会在 D:/cglib_proxy 目录下生成多个 class 文件，其中 OrderService$$EnhancerByCGLIB$$xxxx.class 就是代理类，反编译后可看到其核心结构（简化后）：
public class OrderService$$EnhancerByCGLIB$$1234 extends OrderService implements Factory {
// MethodProxy 对象，用于调用目标方法
private static MethodProxy CGLIB_findOrderById_0;
private static MethodProxy CGLIB_createOrder_1;
// 静态代码块：初始化 MethodProxy
static {
CGLIB_findOrderById_0 = MethodProxy.create(OrderService.class, OrderService$$EnhancerByCGLIB$$1234.class, "(Ljava/lang/Long;)Lcom/example/entity/Order;", "findOrderById", "CGLIB$findOrderById$0");
// ...初始化其他 MethodProxy
}
// 重写 findOrderById 方法
@Override
public Order findOrderById(Long var1) {
MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
if (var10000 == null) {
CGLIB$BIND_CALLBACKS(this);
var10000 = this.CGLIB$CALLBACK_0;
}
// 调用 MethodInterceptor 的 intercept 方法
return var10000 != null ? (Order) var10000.intercept(this, CGLIB$findOrderById$0$Method, new Object[]{var1}, CGLIB_findOrderById_0) : super.findOrderById(var1);
}
// 目标方法的快速调用方法（由 MethodProxy 调用）
final Order CGLIB$findOrderById$0(Long var1) {
return super.findOrderById(var1);
}
// ...其他重写方法和辅助方法
}
反编译后的代码显示，代理类 OrderService$$EnhancerByCGLIB$$1234 继承自 OrderService，重写了 findOrderById 方法，方法内部调用了 MethodInterceptor 的 intercept 方法，这与我们之前的分析完全一致。
JDK 动态代理与 CGLib 动态代理是 Spring AOP 的两大核心支撑，它们在实现原理、适用场景、性能等方面存在显著差异，了解这些差异是开发者在实际开发中做出正确选择的关键。
下表从多个维度对比了 JDK 动态代理与 CGLib 动态代理的核心差异：
| 对比维度 | JDK 动态代理 | CGLib 动态代理 |
|---|---|---|
| 实现原理 | 基于 Java 反射机制，代理类实现目标接口，继承自 Proxy 类 | 基于 ASM 字节码框架，代理类继承目标类，重写非 final 方法 |
| 目标对象要求 | 必须实现至少一个接口 | 无接口要求，但不能是 final 类，目标方法不能是 final 方法 |
| 代理类结构 | 代理类 = 实现目标接口 + 继承 Proxy 类 | 代理类 = 继承目标类 + 实现 Factory 接口 |
| 方法调用方式 | 通过反射调用目标方法，性能相对较低 | 通过 MethodProxy 调用目标方法，避免反射，性能更高 |
| 依赖 | 依赖 Java 原生 API，无需额外引入依赖 | 依赖 CGLib 和 ASM 框架，Spring 已默认集成 |
| 适用场景 | 目标对象实现接口的场景（Spring AOP 默认首选） | 目标对象无接口的场景，或对性能要求较高的场景 |
关于 JDK 动态代理与 CGLib 动态代理的性能，长期存在争议。实际上，两者的性能差异与 JDK 版本密切相关：
为了直观对比两者的性能，我们设计一个简单的性能测试：分别通过 JDK 和 CGLib 代理，调用目标方法 100 万次，统计总耗时。测试代码如下（以 JDK 代理为例，CGLib 类似）：
public class ProxyPerformanceTest {
public static void main(String[] args) {
// 测试次数
int count = 1000000;
// JDK 动态代理性能测试
UserService jdkTarget = new UserServiceImpl();
UserService jdkProxy = (UserService) Proxy.newProxyInstance(
jdkTarget.getClass().getClassLoader(),
jdkTarget.getClass().getInterfaces(),
new LogInvocationHandler(jdkTarget)
);
long jdkStart = System.currentTimeMillis();
for (int i = 0; i < count; i++) {
jdkProxy.findUserById(1L);
}
long jdkEnd = System.currentTimeMillis();
System.out.println("JDK 动态代理 100 万次调用耗时：" + (jdkEnd - jdkStart) + "ms");
// CGLib 动态代理性能测试
OrderService cglibTarget = new OrderService();
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OrderService.class);
enhancer.setCallback(new LogMethodInterceptor());
OrderService cglibProxy = (OrderService) enhancer.create();
long cglibStart = System.currentTimeMillis();
for (int i = 0; i < count; i++) {
cglibProxy.findOrderById(1L);
}
long cglibEnd = System.currentTimeMillis();
System.out.println("CGLib 动态代理 100 万次调用耗时：" + (cglibEnd - cglibStart) + "ms");
}
}
在 JDK 8 环境下的测试结果（仅供参考）：
JDK 动态代理 100 万次调用耗时：120ms
CGLib 动态代理 100 万次调用耗时：80ms
在 JDK 11 环境下的测试结果（仅供参考）：
JDK 动态代理 100 万次调用耗时：75ms
CGLib 动态代理 100 万次调用耗时：82ms
从测试结果可以看出，JDK 版本对两者的性能影响很大。在实际开发中，无需过度纠结于性能差异——除非是高频调用的核心接口，否则两者的性能差距对系统整体影响微乎其微。选择代理方式的核心依据应是目标对象是否实现接口。
Spring AOP 作为成熟的框架，并没有强制要求使用某一种代理方式，而是根据目标对象的类型自动选择合适的代理方式，其核心选择策略如下：
spring: aop: proxy-target-class: true # true 表示强制使用 CGLib 代理，false 表示优先使用 JDK 代理需要注意的是，Spring Boot 2.x 版本中，proxy-target-class 的默认值为 true——这意味着即使目标对象实现了接口，Spring AOP 也会默认使用 CGLib 代理。这一变化的原因是 Spring 团队认为，CGLib 代理在易用性（无接口要求）和性能（JDK 8 及以下版本）上更具优势，同时避免了 JDK 代理只能代理接口的限制。
前面我们分别剖析了 JDK 和 CGLib 动态代理的实现原理，而 Spring AOP 的整体执行流程是将这两种代理技术与切面定义、切入点匹配等逻辑结合起来的完整链路。理解这一流程，能帮助我们从宏观上把握 Spring AOP 的工作机制。
Spring AOP 的核心执行流程可分为"初始化阶段"和"运行阶段"两个部分，每个阶段包含多个关键步骤：
初始化阶段发生在 Spring 容器启动时，核心任务是解析切面定义、生成切入点，并为目标对象准备代理逻辑。具体步骤如下：
运行阶段发生在客户端调用目标对象方法时，核心任务是通过代理对象执行通知逻辑和目标方法。具体步骤如下：
为了让大家更直观地理解 Spring AOP 的整体执行流程，下面我们通过一个完整的 Spring Boot 案例，展示从切面定义到方法调用的全过程。
创建 Spring Boot 项目，引入 spring-boot-starter-web 和 spring-boot-starter-aop 依赖：
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>
</dependencies>
创建 LogAspect 切面类，定义切入点和五种类型的通知：
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.*;
import org.springframework.stereotype.Component;
import java.time.LocalDateTime;
// 切面类：日志切面
@Aspect
@Component
public class LogAspect {
// 切入点：匹配 com.example.service 包下所有类的所有方法
@Pointcut("execution(* com.example.service.*.*(..))")
public void servicePointcut() {}
// 前置通知
@Before("servicePointcut()")
public void beforeAdvice(JoinPoint joinPoint) {
String methodName = joinPoint.getSignature().getName();
System.out.println("【Spring AOP 前置通知】" + LocalDateTime.now() + " 调用方法：" + methodName);
}
// 后置通知
@After("servicePointcut()")
public void afterAdvice(JoinPoint joinPoint) {
String methodName = joinPoint.getSignature().getName();
System.out.println("【Spring AOP 后置通知】方法" + methodName + "调用结束");
}
// 返回通知
@AfterReturning(value = "servicePointcut()", returning = "result")
public void afterReturningAdvice(JoinPoint joinPoint, Object result) {
String methodName = joinPoint.getSignature().getName();
System.out.println("【Spring AOP 返回通知】方法" + methodName + "返回值：" + (result == null ? "无" : result));
}
// 异常通知
@AfterThrowing(value = "servicePointcut()", throwing = "ex")
public void afterThrowingAdvice(JoinPoint joinPoint, Exception ex) {
String methodName = joinPoint.getSignature().getName();
System.out.println("【Spring AOP 异常通知】方法" + methodName + "抛出异常：" + ex.getMessage());
}
// 环绕通知
@Around("servicePointcut()")
public Object aroundAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
String methodName = joinPoint.getSignature().getName();
System.out.println("【Spring AOP 环绕通知 - 前】" + LocalDateTime.now() + " 准备调用方法：" + methodName);
Object result = null;
try {
// 执行目标方法
result = joinPoint.proceed();
System.out.println("【Spring AOP 环绕通知 - 后】方法" + methodName + "执行完成");
} catch (Throwable e) {
System.out.println("【Spring AOP 环绕通知 - 异常】方法" + methodName + "执行异常：" + e.getMessage());
throw e;
}
return result;
}
}
本文通过从基础概念到底层实现、从理论解析到实战案例的层层递进，全面剖析了 Spring AOP 的核心原理与实践应用。从 AOP 解决的代码痛点出发，我们深入理解了其'横切编程'的本质，掌握了切面、通知、切入点等核心概念，并重点拆解了支撑 Spring AOP 的两大动态代理技术——JDK 与 CGLib 动态代理，最终梳理了 Spring AOP 的完整执行链路。这些内容不仅揭示了技术的底层逻辑，更能为实际开发提供清晰的指引。
Spring AOP 的知识体系可归纳为'一个核心目标、两大技术支撑、三个核心环节'：
基于前文的技术对比与原理分析，在实际开发中使用 Spring AOP 时，可遵循以下决策原则：
Spring AOP 的代理选择已实现自动化，但开发者需明确其逻辑并根据场景调整：
proxy-target-class: true，优先使用 CGLib 代理，覆盖接口与无接口两种场景，降低使用成本；切面设计的合理性直接影响系统的可维护性，需注意以下几点：
虽然 Spring AOP 的性能开销通常可忽略，但在高频调用场景下仍需优化：
execution(* *(..))），减少方法匹配的性能消耗；从技术本质来看，Spring AOP 是'动态代理'与'依赖注入'的结合产物——动态代理实现了方法增强的技术能力，依赖注入则实现了切面与目标对象的解耦与管理。这种'技术组合'的思路，为解决复杂问题提供了典范。
随着 Spring 框架的发展，AOP 的实现也在不断优化，但核心思想始终未变。对于开发者而言，掌握底层原理远比单纯使用 API 更重要：理解动态代理的字节码生成逻辑，能快速定位代理相关的异常；明晰通知的执行顺序，可避免切面逻辑冲突；掌握切入点表达式的语法，能精准控制切面作用范围。这些能力不仅适用于 Spring AOP，更能迁移到其他需要'方法增强'的场景（如 RPC 框架的调用增强、分布式追踪的链路埋点等）。
最终，Spring AOP 的价值不仅在于提供了一种技术方案，更在于传递了'分离关注点'的设计思想——在复杂系统中，通过合理拆分功能模块，实现代码的高内聚与低耦合，这正是软件工程的核心追求之一。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online