InvocationTargetException 是构造函数异常的包装器，根本原因需通过 getCause() 获取；应打印 cause 的堆栈、检查构造函数内校验/资源初始化/静态块等逻辑，并核对反射参数类型匹配。
当通过反射创建对象时抛出 InvocationTargetException，说明目标构造函数在执行过程中抛出了异常，而这个异常被封装在 InvocationTargetException 中——它本身不是根本原因，只是“容器”。排查的关键是获取并分析其 getCause()。
查看原始异常（getCause）
反射调用失败时，JVM 会将构造函数内抛出的异常包装成 InvocationTargetException。必须调用 getCause() 才能看到真实异常：
- 不要只打印
e.toString()或e.getMessage()，它们通常只显示 “InvocationTargetException” - 正确做法：
throwable.getCause() != null ? throwable.getCause() : throwable - 推荐直接打印堆栈：
e.getCause().printStackTrace()或记录完整日志
检查构造函数内部逻辑
常见触发点包括：
- 参数校验失败（如传入 null 但构造函数有
Objects.requireNonNull） - 依赖资源初始化失败（如文件读取、数据库连接、配置加载异常）
- 静态块或字段初始化时报错（这些也会在 new 实例时触发）
- 调用了其他可能抛异常的方法（比如解析 JSON、转换类型等）
确认反射调用参数匹配
虽然参数不匹配通常抛 IllegalArgumentException 或 NoSuchMethodException，但若强制绕过类型检查（如用 setAccessible(true) 后传错类型），某些场景下也可能在运行时触发构造函数内的类型转换异常（如 ClassCastException），进而被包装。
立即学习“Java免费学习笔记（深入）”；
- 核对
getConstructor(...)的参数类型是否与实际传入参数 runtime 类型一致 - 注意基本类型和包装类的区别（
int.classvsInteger.class） - 数组、泛型擦除后的真实类型也要留意
简化复现 + 断点调试
如果日志不够清晰，最有效的方式是：
- 用相同参数，直接 new 实例（绕过反射），看是否同样报错
- 在目标类构造函数首行加断点，用 IDE 调试运行反射代码，观察哪一行抛异常
- 临时把构造函数改成 try-catch，打印或抛出更明确的上下文信息
不复杂但容易忽略：InvocationTargetException 是个信号灯，真正的问题永远藏在 getCause() 里。
