CGLIB与JDK动态代理在变量处理上本身无性能差异，因二者均不操作变量而专注方法拦截；参数传递开销几乎为零，成员变量访问不受影响，真正差异在于JDK依赖反射调用（Method.invoke）而CGLIB通过MethodProxy.invokeSuper直接调用，后者路径更短、性能更高。
代理对方法参数的传递开销基本一致
无论是 JDK 还是 CGLIB，代理方法调用时，原始参数（Object[] args）都会被完整传入拦截逻辑：
- JDK 代理中，InvocationHandler.invoke() 直接接收 Object[] args，无额外拷贝或包装
- CGLIB 代理中，MethodInterceptor.intercept() 同样接收原始 args 数组，且通过 MethodProxy.invokeSuper() 转发时复用同一数组
- 两者均不解析、不修改参数内容，也不做深拷贝——参数传递成本几乎为零
成员变量访问不受代理机制影响
代理对象本身不改变目标类对字段的访问方式：
- JDK 代理生成的类（如 $Proxy0）不持有目标对象的字段副本，所有字段访问仍发生在原始 target 实例上
- CGLIB 生成的子类直接继承目标类，其方法内对 this.field 的访问就是原生字节码读取，和非代理场景完全一致
- 代理层不介入字段读写过程，因此不存在“代理导致变量访问变慢”的情况
真正影响性能的其实是方法调用路径
变量相关感知到的“慢”，往往源于底层调用机制差异：
- JDK 代理依赖 Method.invoke()，每次调用需经反射入口、权限检查、参数适配，JDK 8+ 虽有反射优化（如生成委派字节码），但仍有固定开销
- CGLIB 使用 MethodProxy.invokeSuper()，绕过反射，直接跳转到父类原生方法，调用链更短，单次方法执行更快
- 若业务方法频繁读写大量局部变量或循环操作字段，CGLIB 的调用优势会放大；但若只是简单 getter/setter，差距可忽略
启动与内存层面的隐性成本
这会影响含变量初始化的代理对象生命周期表现：
- JDK 代理类生成快、类加载轻量，适合短期、大量创建的场景（如每个请求一个代理）
- CGLIB 需解析目标类字节码、生成子类、注册新类——首次代理创建可能慢 10–100 倍，且每个代理类占用更多 Metaspace
- 若目标类含复杂构造逻辑或初始化大量实例变量，CGLIB 子类继承后，new 代理实例时仍会执行父类构造器，这部分开销与代理无关，但容易被误归因
