InvocationTargetException 是反射调用中封装目标方法异常的包装器，需调用 getCause() 获取原始异常；其 cause 可能为 null 或嵌套多层，须递归解包才能定位真实错误。
InvocationTargetException 是什么包装器
它不是你代码里真正出问题的异常，而是反射调用过程中「被封装了一层」的异常。只要 Method.invoke() 执行的目标方法内部抛了异常，JVM 就会把它包进 InvocationTargetException 里再往外扔——相当于一层“信封”，你得拆开才能看到里面真正的错误。
常见现象：堆栈里看到 InvocationTargetException，但找不到你写的业务逻辑里 throw 的那个 NullPointerException 或 IllegalArgumentException，容易误判成反射框架本身的问题。
怎么拿到原始异常（getCause() 是关键）
必须调用 getCause()，不能直接打印或捕获后就完事。这个方法返回的就是目标方法里实际抛出的那个异常实例。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远对
InvocationTargetException做e.getCause()，而不是e本身 - 如果
getCause()返回 null，说明目标方法是通过System.exit()或 JVM 异常（如OutOfMemoryError）终止的，不是普通异常 - 在日志中记录时，推荐用
log.error("reflect call failed", e.getCause())，而不是e - 不要用
e.getStackTrace()查原始异常位置——它的堆栈是从invoke()开始的，要看e.getCause().getStackTrace()
为什么不能直接 catch 原始异常类型
编译器不知道目标方法会抛什么，所以 Method.invoke() 声明只抛 IllegalAccessException、IllegalArgumentException 和 InvocationTargetException。你没法写 catch (MyBusinessException e)，因为编译不通过。
这意味着：
- 所有运行时异常（包括自定义的
RuntimeException子类）都会被包进InvocationTargetException - 受检异常（checked exception）也会被包进去，但注意：它们不会自动变成运行时异常，仍需在调用处处理或声明
- 如果你要根据原始异常类型做分支处理（比如重试 vs 熔断），必须先解包再
instanceof
示例：
try {
method.invoke(obj, args);
} catch (InvocationTargetException e) {
Throwable cause = e.getCause();
if (cause instanceof BusinessException) {
// 处理业务异常
} else if (cause instanceof TimeoutException) {
// 触发降级
}
}
容易忽略的边界情况
真实场景里，这几个点经常导致排查卡住：
-
getCause()可能是null：比如目标方法执行了return后又触发了finalize()抛异常，或者用了 JNI 导致异常未被正确捕获 - 嵌套多层包装：某些框架（如 Spring AOP）会在反射外再包一层
UndeclaredThrowableException或NestedRuntimeException，这时需要递归调用getCause() - Android 上 Dalvik/ART 对反射异常的包装行为略有差异，低版本可能把
Error也包进去，而不仅仅是Exception - 如果原始异常是
AssertionError，它属于Error，但依然会被包进InvocationTargetException，别以为只有Exception才会被包
复杂点在于：异常链不是单层信封，有时候得剥两三次才到底。别默认只调一次 getCause()。
