MethodProxy.invokeSuper 比 Method.invoke 快，因其跳过反射的访问校验、装箱拆箱、异常包装等开销，通过 FastClass 生成直接字节码调用，性能高15–30倍；仅限 intercept 回调中使用，且必须传原始对象，不可复用或传代理实例；final/private/static/构造方法无法拦截。
MethodProxy.invokeSuper 为什么比 Method.invoke 快
因为 MethodProxy.invokeSuper 不走 Java 反射的完整检查链：它跳过了访问控制校验、参数自动装箱/拆箱、异常包装、调用栈构建等开销步骤。底层通过 FastClass 机制，把方法调用编译成类似 target.methodName(arg0, arg1) 的直接字节码指令，相当于“静态绑定后的动态调用”。实测在高频场景（如每秒万次以上拦截）下，性能差距可达 15–30 倍。
必须用 Enhancer.setCallback 设置 MethodInterceptor 才能用 MethodProxy
MethodProxy 对象只在 MethodInterceptor.intercept() 回调中由 CGLIB 自动注入，不会出现在你手动 new 出来的对象里。如果你试图在别处缓存或复用 MethodProxy 实例，会遇到 NullPointerException 或 IllegalStateException —— 它和代理实例生命周期强绑定。
- 正确姿势：只在
intercept(Object obj, Method method, Object[] args, MethodProxy proxy)的proxy参数里使用 - 错误姿势：把
proxy存到字段里跨方法复用；或试图用Enhancer.create()后再反射获取MethodProxy - 注意：同一个代理类的不同方法调用，传入的
MethodProxy实例不同，不能混用
invokeSuper 的两个参数顺序容易写反
MethodProxy.invokeSuper(obj, args) 的第一个参数必须是被代理的原始对象（即 obj），不是代理对象本身。如果误传代理实例（比如 this 或 proxy），会触发无限递归，最终抛出 StackOverflowError —— 这是线上最常踩的坑之一。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- ✅ 正确：
return proxy.invokeSuper(obj, args); - ❌ 错误：
return proxy.invokeSuper(this, args);（this是代理子类实例） - ❌ 错误：
return proxy.invokeSuper(proxy, args);（同上，且 proxy 是接口类型，类型不匹配）
final 方法和 private 方法无法被 MethodProxy 拦截
CGLIB 生成的是目标类的子类，只能重写 non-final、non-private 的方法。如果你看到某个方法没进 intercept()，先检查它的修饰符：
- final 方法：CGLIB 直接跳过，调用原逻辑，
MethodProxy根本不会创建对应实例 - private 方法：子类不可见，不会被重写，也不会出现在
Method参数中 - static 方法：不属于实例调用链，CGLIB 不处理
- 构造方法：不在方法拦截范围内，需用其他机制（如 ByteBuddy）
这种限制不是 bug，是设计使然。想代理 final 类或方法，得换方案，比如 JDK 动态代理（仅限接口）或运行时字节码改写（如 Java Agent + Instrumentation）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
