java动态代理核心是proxy类必须配合invocationhandler使用，后者决定方法调用行为；proxy仅生成代理对象，不执行逻辑；代理仅支持接口，无接口时需cglib、javassist或byte buddy等字节码增强方案。
Java动态代理核心：Proxy类必须配合InvocationHandler使用
Java原生Proxy类本身不执行代理逻辑，它只是生成代理对象的工厂。真正决定方法调用行为的是你传入的InvocationHandler实现。没有自定义InvocationHandler，Proxy.newProxyInstance()生成的对象调用任何方法都会抛NullPointerException（如果handler为null）或直接失败。
常见错误是只写Proxy.newProxyInstance(...)却忘了实现invoke()方法，或者在invoke()里漏掉method.invoke(target, args)导致目标方法完全没执行。
- 必须实现
InvocationHandler接口，并在invoke()中显式调用目标对象方法（除非你有意拦截） -
Proxy.newProxyInstance()第三个参数不能为null，否则运行时报NullPointerException - 代理对象只能对接口生效，不能代理具体类（这是JDK Proxy的根本限制）
CGLIB和Javassist适合代理没有接口的类
当目标类没有实现任何接口时，Proxy彻底失效。这时需要字节码增强类库：CGLIB（基于ASM）和Javassist（API更友好）。它们通过继承目标类生成子类实现代理，因此目标类不能是final，方法也不能是final或private。
CGLIB性能通常略优于Javassist，但配置稍重；Javassist支持运行时编写Java语法风格的逻辑（比如用insertBefore()注入代码），调试更直观。
立即学习“Java免费学习笔记（深入）”；
-
CGLIB依赖net.sf.cglib.proxy.Enhancer，需设置setSuperclass()和setCallback() -
Javassist需先获取CtClass，再用instrument()或toBytecode()操作字节码 - Spring AOP默认优先用
Proxy，只有目标类无接口时才自动fallback到CGLIB
Byte Buddy是现代替代方案，API更安全、更易读
相比CGLIB和Javassist，Byte Buddy设计上规避了许多运行时陷阱：它默认拒绝增强final类/方法（可显式配置覆盖），内置校验机制，且API以DSL形式组织，意图清晰。例如.method(ElementMatchers.any()).intercept(...)比CGLIB的FixedValue或MethodInterceptor更贴近语义。
它不依赖运行时反射解析，编译期检查更强，出错提示也更明确（比如直接告诉你哪个方法因final被跳过）。Spring 6+已将Byte Buddy作为AOP底层候选之一。
- 无需手动处理
ClassLoader，new ByteBuddy().subclass(...)自动适配 - 拦截逻辑用
Implementation封装，支持MethodDelegation或Advice两种模式 - 对Java 17+的密封类（sealed class）和模块系统兼容性更好
选型关键看三点：有没有接口、是否允许继承、是否需要编译期保障
不是越新越好，也不是越快越好。如果项目只代理接口，Proxy零依赖、无额外jar、线程安全，就是最优解；如果必须代理final工具类，那CGLIB/Javassist/Byte Buddy全都不行——只能改源码或换设计。
容易被忽略的是类加载器问题：CGLIB生成的子类默认使用目标类的ClassLoader，但在OSGi或热部署场景下，若代理类与目标类不在同一ClassLoader，会报ClassNotFoundException或IllegalAccessError。Byte Buddy对此有显式ClassLoadingStrategy控制，而原生Proxy要求所有接口必须能被指定ClassLoader加载。
Proxy.newProxyInstance(
target.getClass().getClassLoader(), // 这个ClassLoader必须能看见所有接口
target.getClass().getInterfaces(),
new MyInvocationHandler(target)
); 
