需穿透多层异常封装定位根本原因：逐层调用getCause()或getRootCause()，识别InvocationTargetException、UndeclaredThrowableException等反射包装异常，结合堆栈中的Method.invoke等反射入口及字节码验证，辅以日志配置%ex{full}和框架配置优化。
排查第三方框架反射调用引发的包装异常链条，核心在于穿透多层异常封装，还原真实异常源头。这类问题常见于 Spring、MyBatis、Dubbo、Lombok 等依赖反射的框架中——它们常将原始异常包裹在 InvocationTargetException、UndeclaredThrowableException、NestedRuntimeException 等中间异常里，堆栈被截断或隐藏关键信息。
定位最内层根本异常（getCause 链式展开）
不要只看异常类名和第一行 message，必须手动或借助工具逐层调用 getCause()。很多 IDE（如 IntelliJ）默认只显示顶层异常，需在调试器中展开“Cause”字段，或在日志中打印完整 cause 链：
- 在 catch 块中添加： log.error("Exception occurred", e); // 确保日志框架支持递归打印 cause
- 若用 Logback/Log4j2，确认配置了
%ex{full}或%xEx，而非仅%ex（后者默认只打一层） - 手写诊断代码时，用循环遍历：
while (e != null) { System.out.println(e.getClass() + ": " + e.getMessage()); e = e.getCause(); }
识别典型反射包装异常类型
熟悉以下常见“中间异常”，能快速判断是否为反射所致：
-
InvocationTargetException：JDK 反射调用方法失败时的必然包装，
getCause()就是真实异常 - UndeclaredThrowableException：动态代理（如 JDK Proxy、Spring AOP）中，被代理方法抛出未声明的受检异常时的包装
-
NestedRuntimeException / DataAccessException：Spring 框架对底层异常（如 SQLException、IOException）的标准化包装，其
getRootCause()方法可直达原始异常 - Lombok @SneakyThrows 生成的 RuntimeException 包装：虽非反射直接引发，但常与反射调用共存，掩盖原始异常类型
结合调试与字节码验证反射入口点
当堆栈中出现 Method.invoke、Constructor.newInstance、Proxy.newProxyInstance、Enhancer.create 等调用时，说明已进入反射上下文：
- 在 IDE 中对这些调用行打断点，观察入参 method、target 对象及实际执行逻辑
- 检查被反射调用的方法签名——是否声明了 throws？若未声明却抛出受检异常，必然触发包装（如 InvocationTargetException）
- 对可疑类使用
javap -c查看字节码，确认 Lombok 生成逻辑或 CGLIB 增强是否引入了隐式 try-catch 包装
在框架配置层面减少异常遮蔽
部分框架提供开关控制异常包装行为：
- Spring Boot 中启用
spring.aop.proxy-target-class=true并配合@EnableAspectJAutoProxy(exposeProxy = true)，有助于更清晰暴露代理链异常 - MyBatis 设置
configuration.defaultExecutorType = SIMPLE可减少 Executor 层异常再包装 - 自定义 ExceptionHandler 时，优先调用
ExceptionUtils.getRootCause(e)（Apache Commons Lang）而非直接处理 e
