受检异常必须声明在接口方法上，因为JDK动态代理生成的代理类方法签名完全继承自接口，JVM校验实际抛出异常是否可分配给接口声明的异常类型，否则抛UndeclaredThrowableException。
在 JDK 动态代理中，InvocationHandler 的 invoke 方法声明只允许抛出 Throwable，但实际调用目标方法时若抛出**受检异常（checked exception）**，必须满足一个关键约束：该异常类型必须在被代理接口的方法签名中显式声明（即出现在 throws 子句里），否则运行时会抛出 UndeclaredThrowableException。
为什么受检异常必须声明在接口方法上？
JDK 动态代理生成的代理类是基于接口的，其方法签名完全继承自接口。JVM 在执行代理方法时，会校验实际抛出的异常是否“可分配给”接口方法声明的异常类型。如果目标方法抛出 IOException，但接口方法没写 throws IOException，代理就无法合法传递该异常，只能包装为 UndeclaredThrowableException（运行时异常）向上抛出。
正确处理方式：接口方法显式声明受检异常
这是最标准、最安全的做法。确保代理接口中每个可能抛出受检异常的方法，都在 throws 中列出对应异常类型：
- 接口方法签名需与目标类方法保持一致（包括
throws） - 目标类实现类可以抛出该异常的子类，只要父类已在接口中声明
-
InvocationHandler.invoke()内直接throw受检异常即可，无需包装
示例：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
public interface Service {
String doWork() throws IOException; // ← 必须声明
}
public class RealService implements Service {
@Override
public String doWork() throws IOException {
throw new IOException("failed");
}
}
// InvocationHandler 中：
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
return method.invoke(target, args); // ← 直接抛出 IOException，合法
}
CGLIB 代理不支持受检异常透传（无接口限制，但仍有约束）
CGLIB 代理基于子类继承，不依赖接口，看似更灵活，但它在方法拦截器（MethodInterceptor）中也面临类似问题：
-
MethodInterceptor.intercept()方法签名同样只声明抛出Throwable - 若目标方法抛出未在被覆盖的父类/接口方法签名中声明的受检异常，CGLIB 会尝试用
net.sf.cglib.core.CodeGenerationException包装（本质也是运行时异常） - 要让受检异常“原样透传”，仍需确保父类或实现的接口方法已声明该异常
不推荐的绕过方式（仅作了解）
强行将受检异常转为运行时异常虽能编译通过，但破坏了异常设计契约：
- 用
new RuntimeException(checkedEx)包装 —— 丢失异常语义，调用方无法针对性捕获 - 用反射修改
throws字节码（如 Javassist）—— 复杂、易出错、破坏可移植性 - 统一用
RuntimeException替代所有业务异常 —— 违背 Java 异常分类原则，降低代码健壮性
本质上，这不是代理框架的限制，而是 Java 类型系统和多态调用机制的要求。遵守接口契约，让异常声明可见、可预期，才是清晰可靠的方案。
