静态代理必须手动写实现类，因为Java编译期锁死类型关系，Proxy无法运行时生成符合接口签名的完整类文件；它本质是人写的“替身类”，需显式实现接口，否则多态失效、强转报ClassCastException。
静态代理为什么必须手动写实现类
因为 Java 编译期就锁死了类型关系，Proxy 类不能在运行时凭空生成一个符合接口签名的完整类文件。静态代理本质是人写的“替身类”，它得显式继承/实现目标行为契约。
常见错误现象：ClassCastException，比如把代理对象强转成具体实现类而非接口；或者代理类没实现全部接口方法，编译直接报错。
- 使用场景：目标接口稳定、代理逻辑简单（如统一日志、权限校验），且不希望引入反射开销
- 必须让代理类和被代理类实现同一接口，否则多态失效
- 代理类中要持有被代理对象引用，调用前/后加逻辑，再转发给真实对象
- 如果接口方法多，代理类容易变成模板代码搬运工，改一个方法就得同步改代理
动态代理绕不开 InvocationHandler 的原因
Java 动态代理不是“生成源码”，而是 JVM 在运行时用 defineClass 注入字节码——但你不能控制那堆字节码怎么写，所以得靠 InvocationHandler 作为统一拦截入口。
常见错误现象：IllegalArgumentException: object is not an instance of declaring class，通常是传进 invoke 的 proxy 对象类型和方法声明类不匹配；或 handler 返回值类型与接口方法声明不一致。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 只能代理接口，不能代理具体类（
CGLIB才能代理类，但那是另一套机制） -
Proxy.newProxyInstance的三个参数缺一不可：类加载器、接口数组、InvocationHandler实例 - 所有接口方法调用最终都落到
invoke方法里，得自己用method.invoke(target, args)转发，漏掉这步就什么也不发生 - 注意
invoke中对toString/hashCode/equals的处理，否则代理对象打印出来是默认地址，集合操作出问题
Proxy.newProxyInstance 的类加载器传错会怎样
类加载器决定生成的代理类归属哪个命名空间。传错会导致代理类和接口“看似同名实则不同类”，哪怕包名方法一模一样，JVM 也认为它们是两个无关类型。
典型表现：ClassCastException，即使你确定实现了接口，强制转型仍失败；或者 proxy.getClass().getClassLoader() 和接口的 getClassLoader() 不一致。
- 最安全做法是用接口的类加载器：
MyInterface.class.getClassLoader() - 千万别用
Thread.currentThread().getContextClassLoader()除非你清楚当前线程上下文类加载器已被显式设置且与目标接口一致 - Web 容器（如 Tomcat）里尤其容易踩坑，应用类加载器、共享库类加载器、容器类加载器层级不同，混用必炸
为什么动态代理比静态代理更难调试
因为代理类根本没源码，javap -c 看到的是 JVM 自动生成的字节码，方法名是 sayHello，但栈帧里显示的是 invoke0 或 doInvoke 这类合成方法名。
你打不了断点，IDE 不认行号，异常堆栈里看不到你写的逻辑位置，只看到 InvocationHandler.invoke 这一层。
- 建议在
invoke开头加if (method.getName().equals("xxx"))单独断点，缩小范围 - 别依赖 IDE 的“Step Into”，它会跳进 JVM 底层；改用 “Step Over” + 日志观察参数和返回值
- 生产环境出问题时，
proxy.getClass().getName()可以帮你确认是不是真的生成了代理类（名字类似$Proxy123）
代理模式真正麻烦的从来不是“怎么写”，而是“怎么让代理行为不干扰原有语义”——比如事务传播、线程上下文传递、泛型擦除后的类型安全，这些都在接口之下悄悄变形。
