InstantiationException 的根本原因不在“有没有无参构造”，而在“能不能调用”：需存在可访问的无参构造函数，且构造过程未抛出未捕获异常；排查时应逐层获取 cause 定位真实异常。
InstantiationException 通常不是直接由“缺少无参构造函数”导致的，而是反射调用 Class.newInstance()（已弃用）或 Constructor.newInstance() 时，底层机制无法完成实例化所抛出的包装异常。真正的原因往往藏在它的 cause 中——多数情况下是 NoSuchMethodException 或更常见的 InvocationTargetException，而后者又可能包裹着 IllegalAccessException、InstantiationException（注意：这是另一个同名但不同层级的异常）或构造函数执行时抛出的业务异常。
根本原因不在“有没有无参构造”，而在“能不能调用”
Java 反射创建对象的关键在于：目标类必须存在一个可访问（public）、无参数的构造函数，且该构造函数不能抛出受检异常（除非被显式捕获处理）。但即使有 public 无参构造，以下情况仍会触发 InstantiationException：
- 构造函数是
private或protected，且未调用setAccessible(true) - 类是抽象类或接口（JVM 禁止直接实例化）
- 类是成员内部类（非 static），实例化时缺少外部类实例引用
- 构造函数执行过程中抛出了未捕获的异常，而上层反射代码只捕获了
InstantiationException却忽略了getCause()
正确排查方式：别只看异常类型，要看 cause
遇到 InstantiationException，第一反应不应该是“赶紧加个无参构造”，而是打印完整堆栈并检查其根本原因：
- 调用
e.getCause()，反复获取直到为null，定位最内层异常 - 若 cause 是
NoSuchMethodException：说明 JVM 找不到匹配的 public 无参构造（注意：默认构造器仅在类中无任何构造器时才自动生成；一旦定义了带参构造，就必须显式写出无参构造） - 若 cause 是
IllegalAccessException：说明构造器存在但不可见，需在获取 Constructor 后调用setAccessible(true) - 若 cause 是
InvocationTargetException：打开它的getTargetException()，查看业务逻辑中实际抛了什么（比如数据库连接失败、配置缺失等）
推荐写法：用 Constructor.newInstance() 替代已废弃的 Class.newInstance()
Class.newInstance() 在 Java 9+ 已标记为废弃，它隐式要求 public 无参构造且无法处理受检异常。现代写法应明确获取构造器并控制访问权限：
- 使用
clazz.getDeclaredConstructor()获取无参构造器（即使 private） - 立即调用
constructor.setAccessible(true) - 再调用
constructor.newInstance()，并捕获InvocationTargetException和IllegalAccessException - 对
InvocationTargetException，务必通过e.getTargetException()暴露真实错误
常见误判场景举例
比如有如下类：
public class User {
private String name;
public User(String name) { this.name = name; }
}
此时没有无参构造，Class.forName("User").getDeclaredConstructor().newInstance() 会直接抛 NoSuchMethodException，而如果代码错误地只捕获 InstantiationException 并忽略 cause，就会误以为是 InstantiationException 导致失败。实际上，InstantiationException 在这个场景下根本不会被抛出——它只会在 newInstance() 调用过程中因 JVM 层限制（如实例化接口）而触发。
