Java原生动态代理强制要求被代理对象实现接口，因其生成的代理类必须继承java.lang.reflect.Proxy且Java不支持多重继承，故只能通过接口定义行为契约；字节码生成器仅处理接口方法，忽略目标类非接口成员；CGLIB等工具则通过字节码增强支持类代理。
Java原生动态代理（java.lang.reflect.Proxy）强制要求被代理对象必须实现至少一个接口，这是由其实现机制决定的，而非设计疏漏或临时限制。
核心原因：Proxy类只能继承java.lang.reflect.Proxy，无法再继承目标类
Java不支持多重继承，而Proxy.newProxyInstance()生成的代理对象是一个新类，该类固定继承自java.lang.reflect.Proxy。这意味着它不能再继承任何其他类（比如你的具体Service实现类）。因此，代理对象无法通过“继承目标类”来复用其方法签名和逻辑——唯一可行的类型抽象方式，就是依赖接口。
例如：
- 你有一个
OrderServiceImpl类实现了OrderService接口； - Proxy生成的代理类是类似
$Proxy0 extends Proxy implements OrderService的结构； - 如果
OrderServiceImpl没有接口，就无法在implements子句中声明行为契约，JVM也就无从知道代理对象该暴露哪些方法。
字节码层面：代理类由ProxyGenerator动态生成，仅支持接口实现
Proxy 内部使用 sun.misc.ProxyGenerator（或其替代实现）生成字节码。该生成器的逻辑明确限定：只遍历传入的接口数组，提取所有 public 方法，生成对应桥接方法，并委托给 InvocationHandler。它完全忽略目标类的非接口方法，也不尝试复制其字段或私有逻辑。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
即使你通过反射强行获取目标类的非接口方法，代理实例也无法响应调用——因为字节码里根本没生成对应的方法体，JVM会直接抛出 UnsupportedOperationException 或 NoSuchMethodError。
与CGLIB的关键区别：技术路线不同，约束自然不同
这不是Java代理“不够强”，而是它选择了基于接口的轻量级方案：
- Java Proxy：运行时生成新类 → 必须继承Proxy → 只能靠接口定义API → 安全、标准、无需额外依赖；
- CGLIB：通过ASM修改目标类字节码 → 生成子类 → 要求目标类不能是final、方法不能是final → 可代理无接口类，但有兼容性和性能权衡。
两者定位不同：前者面向规范抽象（面向接口编程），后者面向实现增强（面向类编程）。
绕过限制？不是“绕过”，而是选对工具
如果你确实需要代理没有接口的类，这不是Java Proxy的缺陷，而是使用场景错配。此时应：
- 优先考虑为关键类提取接口（符合开闭原则与可测性）；
- 若不可行，改用 CGLIB 或 Byte Buddy 等支持类代理的库；
- 注意 Spring AOP 默认使用 Java Proxy，只有当目标类无接口时才自动 fallback 到 CGLIB（需开启
proxy-target-class="true"）。
强行用反射+Unsafe模拟代理，既破坏封装，又失去InvocationHandler的统一拦截能力，得不偿失。
