cglib不继承throws异常声明，因其字节码生成时默认忽略方法签名中的exceptions属性，仅保留方法名、参数和返回类型；jvm中异常声明属可选元数据，cglib为兼容性未主动写入，导致编译期无法感知受检异常。
Java 中 throws 声明的异常**不会自动被 CGLIB 动态代理继承或暴露**，因为 CGLIB 生成的代理类方法签名默认只继承原方法的参数和返回类型，不复制 throws 子句。这是 CGLIB 的设计限制（底层基于 ASM 字节码生成，且为兼容性考虑未主动处理异常声明）。
为什么 CGLIB 不继承 throws 异常声明？
CGLIB 的 MethodInterceptor 拦截逻辑运行在运行时，其生成的代理方法签名由 Enhancer 根据目标方法反射信息“简化”生成 —— 它会保留方法名、参数类型、返回类型，但忽略 throws 列表。JVM 字节码层面，异常声明（Signature）是可选属性，CGLIB 默认不写入，导致编译期无法感知该方法可能抛出哪些受检异常。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
如何让代理方法同步声明 throws 异常？
没有开箱即用的配置开关，需手动干预字节码或绕过 CGLIB 的默认行为。常用可行方案如下：
-
改用 JDK 动态代理（推荐用于接口场景）：JDK 代理严格遵循接口方法签名，
throws会被完整继承。若目标对象实现接口，优先使用Proxy.newProxyInstance。 -
在拦截器中显式 throw 并包装为 RuntimeException：对受检异常做运行时包装（如
throw new RuntimeException(e)），避免编译期检查，但会丢失原始异常类型语义。 -
使用 Byte Buddy 替代 CGLIB：Byte Buddy 支持精准复制方法签名（含
throws），例如通过MethodDescription.Transformer.Default或自定义Implementation保留异常声明。 -
手动增强 CGLIB（不推荐）：通过继承
Enhancer或修改MethodInterceptor的字节码生成逻辑（如 hook ASM 的MethodVisitor），在visitMethod阶段写入exceptions属性 —— 实现复杂且易出错，仅限深度定制场景。
实际影响与规避建议
若业务代码依赖编译期检查（如调用方必须 try-catch 某个 IOException），而代理后该异常未出现在方法签名中，会导致：
• 编译失败（调用方未处理，但代理方法没声明）；
• IDE 提示错误或警告；
• 静态分析工具误报。
建议按场景选择：
• 接口代理 → 用 JDK Proxy；
• 类代理且必须保留受检异常 → 换 Byte Buddy；
• 仅需运行时行为一致 → 统一转为 RuntimeException 子类并文档说明。
不复杂但容易忽略 —— 异常声明不是“行为”，而是编译契约，代理工具是否维护它，取决于其字节码生成策略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
