InvocationTargetException 是什么，为什么它总在反射里冒出来
它不是你代码写错了，而是被反射调用的那个方法自己抛了异常，InvocationTargetException 只是“套壳”——把原始异常包了一层再扔出来。JVM 要求反射调用必须统一用这个包装类，否则没法区分“反射失败”和“目标方法失败”。
常见错误现象：InvocationTargetException 堆栈里看不到你写的业务异常，只看到 getCause() 才是真凶；IDE 调试时断点停在 invoke() 那行，但实际崩溃点在被调方法内部。
- 永远别直接 catch
InvocationTargetException后就吞掉——那等于把真实问题藏起来了 - 必须用
e.getCause()拿出原始异常，再按需处理（比如IllegalArgumentException就该提前校验参数） - 如果被调方法声明抛
Exception，但你没在反射外层 try-catch，它会原样包装成InvocationTargetException再上抛
怎么正确捕获并还原原始异常
核心就一条：别对 InvocationTargetException 做业务逻辑判断，只把它当“快递盒”，拆开看里面是什么。
使用场景：比如用反射调 Spring Bean 的私有方法做单元测试，或动态加载插件里的处理器。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
try {
Object result = method.invoke(target, args);
} catch (InvocationTargetException e) {
Throwable cause = e.getCause();
if (cause instanceof NullPointerException) {
// 处理 NPE
} else if (cause instanceof CustomBizException) {
// 处理业务异常
} else {
throw new RuntimeException("未预期的异常", cause);
}
}
-
e.getCause()可能为 null（极少见，仅当目标方法 throw null 时），要判空 - 不要用
e.getTargetException()—— 这是旧版 API 别名，已废弃，语义也不如getCause()清晰 - 如果原始异常是
Error（比如OutOfMemoryError），getCause()也会如实返回，别假设它一定是Exception
和 ClassNotFoundException、IllegalAccessException 等反射异常的区别
它们根本不在一个层级：InvocationTargetException 是“调用成功但目标方法崩了”，其他几个是“连调用这步都没走通”。
参数差异和兼容性影响：Java 8 到 Java 17 对这些异常的继承关系没变，但 JDK 14+ 的 Method.invoke() 在某些 JIT 优化路径下可能让 getCause() 的堆栈更精简——不影响逻辑，但调试时原始异常的 printStackTrace() 行号可能少几行。
-
NoSuchMethodException：方法名/签名根本找不到，编译期都过不去的错 -
IllegalAccessException：方法是 private/protected 且没调setAccessible(true) -
InstantiationException：反射 new 实例时，类是 abstract 或没无参构造 - 只有
InvocationTargetException的出现，说明反射调用已进入目标方法体，问题在业务逻辑里
容易被忽略的坑：嵌套再嵌套
如果被调方法里又用反射调了别的方法，而那个方法也崩了，getCause() 拿到的可能还是个 InvocationTargetException —— 也就是套娃。
性能影响：连续多层 getCause() 不耗性能，但递归解包容易漏掉深层原因，尤其日志只打了一层。
- 简单场景用一次
e.getCause()够用；复杂插件体系建议写个工具方法递归取 root cause - Log 框架如 Logback 默认不展开 cause 链，要用
%ex{full}或等价配置才能打印完整嵌套 - Spring 的
ReflectionUtils.invokeMethod()会自动 unwrap 一层，但如果你用原生Method.invoke()，就得自己动手
最麻烦的情况不是不会解包，而是解完发现原始异常早被吃掉了——比如某中间件 catch 了 Exception 却只 log 一句“执行失败”，连 getCause().toString() 都没打。这时候得翻被调方法源码，而不是在反射层死磕。
