Spring CGLIB动态代理深度解析：从Enhancer到Objenesis的完整实现链路

1. 为什么需要单独聊 CGLIB 动态代理

很多人第一次接触 Spring AOP 的时候，脑子里记住的就是一句"JDK 动态代理基于接口，CGLIB 基于继承"。这句话本身没错，但如果你只停在这一层，遇到实际问题基本就抓瞎了。比如你写了一个@Aspect切面，目标类明明有接口，结果代理对象却报ClassCastException；又或者目标方法被final修饰，切面死活不生效，你翻遍配置也找不到原因。这些坑的根源，都藏在 CGLIB 动态代理的实现细节里。

这篇文章我打算把 Spring 中 CGLIB 这条线彻底拆开讲。从它和 JDK 动态代理的分工边界，到Enhancer怎么生成子类、MethodInterceptor怎么织入回调、CallbackFilter怎么按方法分发拦截逻辑，再到 Spring 是怎么通过Objenesis绕过构造器创建代理实例的。中间会穿插大量源码片段和我自己踩过的坑，尽量做到你看完能自己复现一个简化版的 CGLIB 代理，也能在遇到代理失效时快速定位问题。

适合谁看？如果你已经用过 Spring AOP，能写切面、能配@Pointcut，但对底层"代理对象到底怎么来的"一直模模糊糊，那这篇就是给你准备的。如果你完全没接触过 AOP，建议先把 JDK 动态代理那部分看一遍再回来，因为 CGLIB 的很多设计思路是跟 JDK 代理对照着来的，单独看会缺少参照系。

需要提前说明的是，本文涉及的源码基于 Spring 5.x 和 CGLIB 3.x 这条常见组合，不同版本在类名和包路径上可能有细微差异，但核心机制是稳定的。我尽量把版本相关的点标注出来，避免你照着老版本代码在新版本里找不到类。

2. CGLIB 与 JDK 动态代理的分工逻辑

2.1 两种代理的本质差异

要理解 Spring 为什么同时保留两套代理机制，得先搞清楚它们各自的硬约束。

JDK 动态代理的核心是java.lang.reflect.Proxy，它生成代理对象的唯一途径是"实现目标类所实现的接口"。也就是说，代理类和目标类之间是"兄弟关系"，都实现了同一个接口。这就带来一个天然限制：如果目标类没有实现任何接口，JDK 代理直接歇菜。

CGLIB 走的是另一条路。它在运行时通过字节码生成技术，动态创建一个目标类的子类，然后在这个子类里覆盖父类的非 final 方法，把拦截逻辑塞进去。代理类和目标类之间是"父子关系"。所以它能代理没有接口的类，但代价是不能代理 final 类，也不能拦截 final 方法、private 方法、static 方法。

我把两者的关键差异整理成一张表，方便你对照记忆：

这张表里有个容易被忽略的点：创建速度和执行速度是两回事。CGLIB 第一次创建代理时要生成字节码，开销比 JDK 代理大；但代理对象一旦创建好，后续方法调用的性能通常优于 JDK 的反射调用。所以在"代理对象会被反复创建"的场景下，CGLIB 未必划算；而在"代理对象创建一次、调用很多次"的场景下，CGLIB 更有优势。

2.2 Spring 的代理选择策略

Spring 在DefaultAopProxyFactory里做代理选择，核心逻辑大致是这样的：

// 简化后的判断逻辑 if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) { Class<?> targetClass = config.getTargetClass(); if (targetClass == null) { throw new AopConfigException("TargetSource cannot determine target class..."); } if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) { return new JdkDynamicAopProxy(config); } return new ObjenesisCglibAopProxy(config); } else { return new JdkDynamicAopProxy(config); }

翻译成人话就是三条规则：

1. 如果显式开启了proxyTargetClass=true，或者开启了optimize，优先走 CGLIB。
2. 如果目标类本身是接口，或者已经是 JDK 代理类，那还是走 JDK 代理。
3. 如果目标类没有实现任何用户提供的接口，走 CGLIB。

这里有个历史背景值得说一下。Spring Boot 从 2.x 开始，spring.aop.proxy-target-class默认值变成了true，也就是说默认优先使用 CGLIB。这个改动当年引起过不少讨论，原因是很多人习惯了"面向接口代理"，突然发现注入的实现类变成了 CGLIB 子类，某些依赖具体类型的场景行为变了。如果你在 Spring Boot 项目里发现代理类型和预期不符，先检查这个配置。

注意：proxyTargetClass=true并不意味着"一定用 CGLIB"。如果目标类本身是接口，Spring 仍然会用 JDK 代理，因为接口没法被继承生成子类。这个边界条件很多人会搞混。

2.3 为什么 Spring 不干脆只用一种

既然 CGLIB 能代理接口实现类（因为实现类本身不是接口），为什么还要保留 JDK 代理？我理解主要有两个原因。

第一是兼容性和稳定性。JDK 代理是 JDK 自带的，不依赖第三方字节码库，行为可预期。CGLIB 早期版本在某些 JDK 上生成字节码会出问题，尤其是涉及模块化、类加载器隔离的场景。保留 JDK 代理作为兜底，能降低风险。

第二是语义清晰。面向接口编程时，代理对象实现接口，调用方只依赖接口，代理类型对调用方透明。而 CGLIB 生成的子类会暴露目标类的所有非 final 方法，如果目标类有内部状态或者方法间互相调用，代理行为可能和预期不一致。这一点后面讲"自调用失效"时会详细展开。

3. CGLIB 生成代理子类的核心机制

3.1 Enhancer 的角色与工作流程

CGLIB 的核心入口是net.sf.cglib.proxy.Enhancer。你可以把它理解成一个"子类工厂"：你告诉它父类是谁、要回调什么逻辑，它给你吐出一个子类的 Class 对象，你再通过这个 Class 创建实例。

一个最简化的使用流程是这样的：

Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(TargetService.class); enhancer.setCallback(new MethodInterceptor() { @Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { System.out.println("before: " + method.getName()); Object result = proxy.invokeSuper(obj, args); System.out.println("after: " + method.getName()); return result; } }); TargetService proxy = (TargetService) enhancer.create(); proxy.doSomething();

这段代码背后，Enhancer做了几件关键的事：

1. 确定父类：通过setSuperclass拿到目标类，校验它不能被 final 修饰。
2. 收集可覆盖方法：扫描父类所有非 final、非 private、非 static 的方法，包括从父类继承来的。
3. 生成子类字节码：用 ASM 生成一个继承目标类的子类，为每个可覆盖方法生成一个重写版本。
4. 织入回调分发：在每个重写方法里，插入对MethodInterceptor的调用，并把方法信息、参数、MethodProxy传进去。
5. 创建实例：通过Objenesis或默认构造器创建子类实例，绑定回调。

这里第 5 步是个很有意思的设计。CGLIB 创建代理实例时，默认会尝试调用父类的无参构造器。但如果父类没有无参构造器，或者构造器有副作用（比如启动线程、连接资源），直接调用就会出问题。Spring 用的是ObjenesisCglibAopProxy，它借助Objenesis库在不调用任何构造器的情况下创建对象实例。这个技巧后面单独讲。

3.2 生成的子类长什么样

光看流程还是抽象，我们直接看 CGLIB 生成的子类大致结构。假设目标类是这样：

public class UserService { public String findName(Long id) { return "user-" + id; } public void save(String name) { System.out.println("save: " + name); } }

CGLIB 生成的子类，反编译后大概长这样（我省略了无关细节）：

public class UserService$$EnhancerByCGLIB$$xxxx extends UserService { private MethodInterceptor callback; @Override public String findName(Long id) { MethodInterceptor tmp = this.callback; if (tmp == null) { return super.findName(id); } return (String) tmp.intercept(this, method_findName, new Object[]{id}, methodProxy_findName); } @Override public void save(String name) { MethodInterceptor tmp = this.callback; if (tmp == null) { super.save(name); return; } tmp.intercept(this, method_save, new Object[]{name}, methodProxy_save); } }

几个关键点：

• 子类继承了UserService，所以它是目标类的子类型，可以强转。
• 每个被覆盖的方法里，都持有一个MethodInterceptor引用，方法体就是"把调用转发给拦截器"。
• 每个方法对应一个静态的Method对象和一个MethodProxy对象，避免每次调用都反射查找方法。
• 如果拦截器为 null，直接走super调用，相当于不代理。

MethodProxy是 CGLIB 性能优化的关键。它内部持有一个FastClass，通过方法索引直接定位到目标方法，避免了Method.invoke的反射开销。proxy.invokeSuper(obj, args)就是通过FastClass调用父类方法，而不是通过反射。

3.3 CallbackFilter 与多回调分发

实际场景里，一个代理类往往不止一种拦截逻辑。比如有些方法要加事务，有些方法要加日志，有些方法什么都不做。CGLIB 用CallbackFilter来解决这个问题。

CallbackFilter的accept方法接收一个Method，返回一个整数索引，表示这个方法该用第几个回调。Enhancer在生成字节码时，会根据这个索引，在每个方法里插入不同的回调调用。

enhancer.setCallbacks(new Callback[]{txInterceptor, logInterceptor, NoOp.INSTANCE}); enhancer.setCallbackFilter(new CallbackFilter() { @Override public int accept(Method method) { if (method.getName().startsWith("save")) { return 0; // 事务 } if (method.getName().startsWith("find")) { return 1; // 日志 } return 2; // 不拦截 } });

Spring AOP 正是用这套机制来实现"只拦截匹配切点的方法"。DynamicAdvisedInterceptor是 Spring 注入的主要回调，它内部会拿Method去匹配所有 Advisor，只有匹配上的才执行通知链，没匹配上的直接invokeSuper。所以 Spring 的 CGLIB 代理并不是"所有方法都走一遍通知判断"，而是在CallbackFilter层面就做了初步分流，减少不必要的开销。

实操心得：如果你自己写 CGLIB 代理做性能优化，CallbackFilter的accept方法会被频繁调用，里面不要放耗时逻辑。我见过有人在accept里查数据库判断方法类型，结果代理创建阶段就卡住了。

4. Spring 中 CGLIB 代理的完整实现链路

4.1 ObjenesisCglibAopProxy 的创建过程

Spring 的 CGLIB 代理入口是ObjenesisCglibAopProxy，它继承自CglibAopProxy。核心方法getProxy大致做了这些事：

// 简化后的核心步骤 Enhancer enhancer = createEnhancer(); if (targetClass != null) { enhancer.setSuperclass(targetClass); enhancer.setUseFactory(false); } enhancer.setCallbackFilter(new ProxyCallbackFilter(...)); enhancer.setCallbacks(new Callback[]{dynamicAdvisedInterceptor, ...}); // 关键：用 Objenesis 创建实例 return createProxyClassAndInstance(enhancer, callbacks);

createProxyClassAndInstance里有个分支判断，如果开启了optimize或者目标类没有无参构造器，就走Objenesis路径：

protected Object createProxyClassAndInstance(Enhancer enhancer, Callback[] callbacks) { Class<?> proxyClass = enhancer.createClass(); Object proxyInstance = null; if (objenesis.isWorthTrying()) { try { proxyInstance = objenesis.newInstance(proxyClass, enhancer.getUseCache()); } catch (Throwable ex) { // 回退到常规构造器创建 } } if (proxyInstance == null) { proxyInstance = proxyClass.getDeclaredConstructor().newInstance(); } ((Factory) proxyInstance).setCallbacks(callbacks); return proxyInstance; }

Objenesis的价值在于：它通过sun.reflect.ReflectionFactory或者Unsafe直接分配对象内存，跳过了构造器调用。这样即使目标类的构造器需要参数、或者构造器里有副作用，代理实例也能正常创建。

这个设计解决了一个很实际的问题。假设你的 Service 类构造器里注入了十几个依赖，或者构造器里做了参数校验，CGLIB 如果老老实实调构造器，就得把参数都准备好，这显然不现实。Objenesis让代理实例的创建和目标类的构造逻辑彻底解耦。

4.2 DynamicAdvisedInterceptor 的拦截逻辑

DynamicAdvisedInterceptor是 Spring CGLIB 代理的核心回调，它实现了MethodInterceptor。它的intercept方法大致逻辑是：

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable { Object target = getTarget(); Class<?> targetClass = (target != null ? target.getClass() : null); List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass); Object retVal; if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) { // 没有通知，直接调用目标方法 retVal = methodProxy.invoke(target, args); } else { // 构建通知链并执行 retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed(); } return processReturnType(proxy, target, method, retVal); }

这里有几个细节值得展开。

第一，getInterceptorsAndDynamicInterceptionAdvice会拿当前Method去匹配所有 Advisor，返回一个拦截器链。如果链为空，说明这个方法不需要增强，直接methodProxy.invoke(target, args)调用目标对象。注意这里是invoke而不是invokeSuper，因为要调用的是目标对象的方法，而不是代理对象父类的方法。

第二，CglibMethodInvocation继承自ReflectiveMethodInvocation，它重写了invokeJoinpoint方法，用MethodProxy.invoke来调用目标方法，而不是反射。这是 CGLIB 路径的性能优势所在。

第三，processReturnType处理返回值类型转换，主要是应对null返回值在基本类型上的处理。

4.3 自调用失效的根因分析

这是 CGLIB 代理最经典的坑，也是面试高频问题。现象是：同一个类里，方法 A 调用方法 B，方法 B 上配了切面，但切面不生效。

原因在于：代理对象调用方法 A 时，进入的是代理子类的 A 方法，拦截器执行完通知后，通过methodProxy.invoke(target, args)调用的是目标对象的 A 方法。目标对象的 A 方法里再调用 B，这个调用是this.B()，this是目标对象本身，不是代理对象。所以 B 的调用完全绕过了代理，切面自然不生效。

用代码说明：

public class OrderService { public void createOrder() { this.sendNotify(); // 这里的 this 是目标对象，不是代理 } @Transactional public void sendNotify() { // 事务不会生效 } }

解决办法有几种：

1. 注入自身代理：通过AopContext.currentProxy()拿到当前代理对象，用代理对象调用。需要开启exposeProxy=true。
2. 拆分到不同类：把 B 方法挪到另一个 Bean 里，通过依赖注入调用。
3. 用 ApplicationContext 获取代理：从容器里重新拿一次 Bean。

我个人更推荐第二种，拆类是最干净的方案，不依赖 AOP 的运行时状态，也避免了exposeProxy带来的额外开销。第一种方案虽然方便，但AopContext依赖 ThreadLocal，在异步场景下容易出问题。

注意：exposeProxy=true会让 Spring 把当前代理对象放进ThreadLocal，如果方法内部开了新线程，ThreadLocal不会传递过去，AopContext.currentProxy()会抛异常。异步场景慎用。

5. 常见问题排查与避坑实录

5.1 代理失效的典型场景速查

我把实际工作中遇到的 CGLIB 代理失效场景整理成一张表，方便你对照排查：

这张表里，构造器注入依赖为 null这一条特别隐蔽。因为Objenesis跳过了构造器，如果目标类依赖构造器里赋值的字段，代理对象上这些字段就是默认值。不过要注意，Spring 的代理对象只是"外壳"，真正执行逻辑时调用的是目标对象的方法，目标对象是通过正常流程创建的，构造器是执行过的。所以这个问题只在"直接访问代理对象字段"时才会出现，正常方法调用不受影响。

5.2 代理类命名与调试技巧

CGLIB 生成的代理类名字长这样：UserService$$EnhancerByCGLIB$$a1b2c3d4。中间那串十六进制是哈希值，每次生成可能不同。调试时如果想看代理类的真实结构，可以开启 CGLIB 的调试模式：

System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "/tmp/cglib-debug");

设置这个属性后，CGLIB 会把生成的字节码写到指定目录，你可以用反编译工具打开看。这个技巧在排查"为什么某个方法没被拦截"时特别有用，直接看生成的子类里有没有覆盖那个方法，一目了然。

另外，Spring 提供了AopUtils和AopProxyUtils两个工具类，可以帮你判断一个对象是不是代理、是哪种代理：

boolean isAopProxy = AopUtils.isAopProxy(bean); boolean isCglibProxy = AopUtils.isCglibProxy(bean); boolean isJdkProxy = AopUtils.isJdkDynamicProxy(bean); Class<?> targetClass = AopProxyUtils.ultimateTargetClass(bean);

ultimateTargetClass能穿透多层代理拿到最终的目标类，在写通用工具时很有用。

5.3 性能相关的实测经验

关于 CGLIB 和 JDK 代理的性能，网上数据很多，但结论差异很大。我自己做过一组简单的压测，场景是"代理对象创建一次，方法调用一百万次"，结果大致是：

• CGLIB 首次创建耗时约为 JDK 代理的 3 到 5 倍。
• 稳定调用阶段，CGLIB 的吞吐量比 JDK 代理高约 20% 到 40%。
• 如果方法参数是基本类型，CGLIB 的优势更明显，因为避免了装箱。

但这个数据只能作为参考，实际差异取决于 JVM 版本、方法复杂度、调用频率。我的建议是：不要为了性能刻意选 CGLIB，优先根据"有没有接口""需不需要代理具体类"来做选择。性能差异在绝大多数业务场景下可以忽略，而代理失效带来的 bug 才是真正要命的。

如果确实遇到代理性能瓶颈，优先考虑的是减少代理层数、缩小切点范围，而不是换代理类型。我见过一个项目，切点写成execution(* com.xxx..*.*(..))，几乎拦截了所有方法，每个方法调用都要走一遍通知链匹配，性能自然好不了。把切点收窄到具体注解，性能立刻上来了。

6. 手写一个简化版 CGLIB 代理

6.1 用 Enhancer 复现核心流程

光看源码不够直观，我们动手写一个完整的例子，把 CGLIB 的核心用法串一遍。这个例子模拟一个"方法耗时统计"的切面。

public class TimingInterceptor implements MethodInterceptor { @Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { long start = System.nanoTime(); try { return proxy.invokeSuper(obj, args); } finally { long cost = System.nanoTime() - start; System.out.println(method.getName() + " cost: " + cost / 1000 + " us"); } } } public class DemoService { public String query(String key) { try { Thread.sleep(10); } catch (InterruptedException e) { } return "value-" + key; } public void update(String key) { try { Thread.sleep(5); } catch (InterruptedException e) { } } } public class Main { public static void main(String[] args) { Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(DemoService.class); enhancer.setCallback(new TimingInterceptor()); DemoService proxy = (DemoService) enhancer.create(); proxy.query("a"); proxy.update("b"); } }

运行结果会打印出两个方法的耗时。这个例子虽然简单，但已经包含了 CGLIB 代理的全部核心要素：Enhancer配置、MethodInterceptor实现、invokeSuper调用。

6.2 加上 CallbackFilter 做方法级分流

现在升级一下，让query走耗时统计，update走日志记录，其他方法不拦截。

public class LogInterceptor implements MethodInterceptor { @Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { System.out.println("call: " + method.getName() + ", args: " + Arrays.toString(args)); return proxy.invokeSuper(obj, args); } } public class Main { public static void main(String[] args) { Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(DemoService.class); enhancer.setCallbacks(new Callback[]{ new TimingInterceptor(), new LogInterceptor(), NoOp.INSTANCE }); enhancer.setCallbackFilter(new CallbackFilter() { @Override public int accept(Method method) { if ("query".equals(method.getName())) return 0; if ("update".equals(method.getName())) return 1; return 2; } }); DemoService proxy = (DemoService) enhancer.create(); proxy.query("a"); proxy.update("b"); } }

这里NoOp.INSTANCE是 CGLIB 提供的空实现，表示"不拦截，直接调用父类方法"。用NoOp比用null更安全，因为 CGLIB 内部对null回调有特殊处理，容易出意外。

6.3 用 Objenesis 绕过构造器

最后演示一下Objenesis的用法。假设DemoService没有无参构造器：

public class DemoService { private final String prefix; public DemoService(String prefix) { this.prefix = prefix; } public String query(String key) { return prefix + "-" + key; } }

直接用enhancer.create()会报错，因为找不到无参构造器。这时候用Objenesis：

Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(DemoService.class); enhancer.setCallback(new TimingInterceptor()); Class<?> proxyClass = enhancer.createClass(); Objenesis objenesis = new ObjenesisStd(); Object proxy = objenesis.newInstance(proxyClass); ((Factory) proxy).setCallbacks(new Callback[]{new TimingInterceptor()}); DemoService service = (DemoService) proxy; service.query("a"); // 可以调用，但 prefix 字段是 null

注意最后一行注释：prefix字段是null，因为构造器没执行。这正好印证了前面说的"Objenesis 跳过构造器"的副作用。所以这个技巧只适合"代理对象只作为调用入口、不直接访问字段"的场景，Spring AOP 正是这种场景。

实操心得：如果你自己写框架用 Objenesis，一定要确保代理对象创建后，所有依赖都通过 setter 或字段注入补齐，不要依赖构造器初始化。否则会出现"方法能调用，但内部状态是空的"这种诡异问题。

7. 从源码看 Spring 的设计取舍

7.1 为什么用 MethodProxy 而不是 Method

前面提到MethodProxy内部用FastClass做方法索引，避免反射。这个设计的收益到底有多大？我做过一个粗略对比：在百万次调用的场景下，Method.invoke的耗时大约是MethodProxy.invokeSuper的 2 到 3 倍。这个差距在高频调用场景下是实打实的。

但MethodProxy也有代价。它需要在代理类生成阶段额外生成FastClass字节码，增加了类加载和内存开销。所以 CGLIB 代理的"创建成本"比 JDK 代理高，一部分就来自这里。Spring 在CglibAopProxy里对FastClass做了缓存，同一个目标类的多个代理实例可以复用，缓解了这个问题。

7.2 为什么 Spring 5.x 之后更倾向 CGLIB

Spring Boot 2.x 把proxyTargetClass默认值改成true，背后有几个考量。

一是开发体验。很多开发者写 Service 时不习惯先定义接口，直接写实现类。如果默认用 JDK 代理，这些类就没法被代理，切面不生效，排查起来很费劲。默认 CGLIB 能覆盖更多场景。

二是CGLIB 的成熟度提升。早期 CGLIB 在 JDK 高版本上有兼容问题，随着版本迭代，这些问题基本解决了。Spring 5.x 内置的 CGLIB 版本对 JDK 8 到 JDK 17 都有良好支持。

三是性能考量。前面说过，CGLIB 在稳定调用阶段有优势，对于大多数"创建一次、调用多次"的 Bean 来说，这个优势是正向的。

不过这个默认值改动也带来了一些兼容问题。比如有些代码依赖bean instanceof SomeInterface判断，如果代理对象是 CGLIB 子类，instanceof接口判断仍然成立（因为子类实现了接口），但bean.getClass() == SomeImpl.class这种判断就会失败。升级 Spring Boot 版本时，这类隐式依赖要特别注意。

7.3 代理层数过深的问题

Spring 的代理是可以叠加的。比如一个 Bean 同时被@Transactional和自定义切面增强，可能生成多层代理。每层代理都会增加一次方法调用开销，也会让调试变得更复杂。

我遇到过最夸张的情况是一个 Bean 被套了四层代理，堆栈信息长得没法看，排查问题时完全找不到真正的目标方法。后来通过AopProxyUtils.ultimateTargetClass才定位到问题。

减少代理层数的办法：合并切面、用@Order控制顺序、避免在切面里再触发代理。如果发现代理层数异常，可以用Advised接口查看当前 Bean 上挂了哪些 Advisor：

if (bean instanceof Advised) { Advisor[] advisors = ((Advised) bean).getAdvisors(); for (Advisor advisor : advisors) { System.out.println(advisor); } }

这个技巧在排查"切面执行顺序不对"时特别有用，能直接看到 Advisor 的排列顺序。

8. 几个容易被问到的细节问题

8.1 CGLIB 代理对象的 equals 和 hashCode

CGLIB 生成的子类默认不重写equals和hashCode，所以代理对象的这两个方法继承自Object，比较的是引用地址。这意味着：同一个目标对象生成的两个代理实例，equals返回 false。

这个行为在某些场景下会出问题。比如你把代理对象放进HashSet，然后用另一个代理实例去contains，会返回 false。Spring 在CglibAopProxy里对equals和hashCode做了特殊处理，让代理对象在比较时委托给目标对象。具体逻辑在ProxyCallbackFilter里，equals和hashCode会被路由到专门的EqualsInterceptor和HashCodeInterceptor。

如果你自己写 CGLIB 代理，记得处理这两个方法，否则集合操作会出意外。

8.2 代理对象的 toString

同理，toString默认返回的是代理类的名字，不是目标对象的信息。Spring 也做了处理，让toString委托给目标对象。这个细节在日志打印时很重要，否则你看到的全是UserService$$EnhancerByCGLIB$$xxx@1234，完全不知道是哪个对象。

8.3 泛型方法的桥接问题

如果目标类有泛型方法，编译器会生成桥接方法（bridge method）。CGLIB 在扫描可覆盖方法时，需要正确处理桥接方法，否则可能出现"方法被覆盖了两次"或者"泛型方法没被拦截"的问题。

Spring 在CglibAopProxy里通过AopUtils.getMostSpecificMethod来定位最具体的方法，避免桥接方法带来的干扰。这个细节比较深，一般业务开发遇不到，但如果你在写通用框架，需要留意。

9. 我个人的一些实操体会

聊了这么多源码和机制，最后说几个我在实际项目里总结的经验。

第一，不要迷信"默认配置"。Spring Boot 默认用 CGLIB，但这不代表所有场景都合适。如果你的项目是严格的面向接口编程，显式配置proxyTargetClass=false用 JDK 代理，语义更清晰，代理行为也更可预期。

第二，切点范围宁小勿大。我见过太多项目切点写成拦截整个包，结果每个方法调用都要走一遍通知链匹配。把切点收窄到具体注解或具体方法名，性能提升立竿见影，调试也更容易。

第三，自调用问题优先拆类。虽然AopContext.currentProxy()很方便，但它依赖 ThreadLocal，在异步、线程池场景下容易出问题。拆成两个 Bean 是最稳妥的方案，虽然多写一个类，但省去了很多运行时的心智负担。

第四，调试代理问题先看代理类型。遇到切面不生效，第一步用AopUtils.isCglibProxy和isJdkDynamicProxy确认代理类型，第二步用ultimateTargetClass确认目标类，第三步检查方法修饰符。这三步走完，八成问题都能定位。

第五，升级 Spring 版本时重点测代理相关逻辑。代理默认策略、CGLIB 版本、Objenesis 行为在不同版本间都可能有变化。尤其是从 Spring Boot 1.x 升到 2.x，proxyTargetClass默认值变了，依赖具体类型的代码可能出问题。升级前把涉及 AOP 的集成测试跑一遍，能省很多事后排查的时间。

这些经验谈不上多高深，但都是踩过坑之后才记住的。源码分析的价值不在于背下多少类名，而在于遇到问题时，你能快速判断"这是哪一层的问题"，然后直奔对应的源码去找答案。CGLIB 这条线，核心就是"子类生成 + 回调分发 + 实例创建"三件事，把这三件事吃透，剩下的都是细节。