InvocationTargetException是反射调用中目标方法抛出异常的包装器，真实异常需通过getCause()获取；其detailMessage为空不表示异常为空，关键线索在“Caused by”行。
InvocationTargetException 不是真正的错误，而是方法内部异常的“信封”。它本身不说明问题根源，只表示：反射调用已成功启动，但目标方法执行时崩了。
为什么 Java 要用 InvocationTargetException 包一层？
反射是跨方法边界的调用机制，JVM 需要区分两类异常：
- 反射框架自身出错（如找不到方法、权限不足）→ 抛
NoSuchMethodException、IllegalAccessException等 - 目标方法业务逻辑出错（如除零、空指针、数组越界）→ 不能直接抛原异常，否则会和反射层异常混淆
所以 JVM 统一将业务异常包装成 InvocationTargetException，保证反射 API 的异常体系干净、可预测。
真实异常藏在哪？必须用 getCause()
堆栈里写的 Caused by: xxx 就是你要找的线索。直接调用 e.getCause() 才能拿到原始异常对象：
- 如果
e.getCause() == null，说明目标方法执行了throw null（极少见，属代码缺陷） - 常见 cause 类型：
ArithmeticException、NullPointerException、IllegalArgumentException、RuntimeException子类等 - 注意：
getCause()返回的是Throwable，需向下转型才能调用具体方法（如getMessage()）
别被日志里的 “null” 迷惑
日志常显示 InvocationTargetException: null，这不是空指针异常，而是因为该异常的 detailMessage 字段默认为空 —— JVM 在包装时不复制原异常消息。真正信息全在 Caused by 行。
- 错误做法：只打印
e.toString()或e.getMessage() - 正确做法：始终检查
e.getCause()，并用e.getCause().printStackTrace()或结构化日志记录完整链路
提前防御比事后捕获更有效
很多 InvocationTargetException 其实可以避免：
- 调用前验证参数合法性（例如非空、范围、类型兼容性）
- 私有方法调用务必加
method.setAccessible(true)，否则先抛IllegalAccessException - 静态方法调用时传
null作实例参数；实例方法则确保对象非 null - 使用
getDeclaredMethod时确认方法存在且签名精确匹配（参数数量、类型顺序）
