因为JVM在字节码验证阶段就禁止实例化抽象类或接口，反射调用newInstance()时若目标类为abstract或interface，立即抛InstantiationException。
为什么 new 一个抽象类会抛 InstantiationException
因为 JVM 明确禁止直接实例化 abstract 类或 interface。这不是运行时“偶然出错”，而是字节码验证阶段就拒绝的硬性限制——哪怕你用 Class.forName("X").newInstance() 或反射调用 getDeclaredConstructor().newInstance()，只要目标类是抽象的或接口，就会立刻炸出 InstantiationException。
常见错误现象：
- 动态加载配置类名后直接
clazz.newInstance()，结果类其实是抽象基类 - Spring 的
@Bean方法里写了return new AbstractService()，启动报错 - MyBatis 的
resultType指向了接口，查询时触发反射实例化失败
实操建议：
- 检查报错栈顶的
at ... newInstance行，定位具体哪个Class对象被误用了 - 用
clazz.isInterface()和clazz.isAssignableFrom(AbstractClass.class)提前校验，别等抛异常 - 抽象类要实例化？必须通过其非抽象子类，且该子类要有无参构造器（否则抛
NoArgsConstructor相关异常）
反射创建对象时怎么避开 InstantiationException
反射本身不特殊，它只是把编译期检查推迟到运行时——所以问题本质没变：不能实例化抽象类或接口。但容易忽略的是，Class.getConstructor().newInstance() 在 Java 9+ 已标记为废弃，且默认对 private 构造器更严格。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 优先用
Constructor<t> ctor = clazz.getDeclaredConstructor(); ctor.setAccessible(true); ctor.newInstance()</t>，尤其当目标类构造器是private时 - 若
clazz是接口，必须改用它的某个实现类，比如Map.class→ 改用HashMap.class - 避免依赖
Class.newInstance()（已废弃），它不支持带参数构造、不处理检查型异常，还容易在模块化环境下失败
示例：正确绕过抽象类限制
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
Class<?> target = Class.forName("com.example.MyAbstractHandler");
// ❌ 错误：target 是 abstract class
// target.getDeclaredConstructor().newInstance();
// ✅ 正确：找它的具体实现
Class<?> impl = Class.forName("com.example.MyConcreteHandler");
impl.getDeclaredConstructor().newInstance();
InstantiationException 和 NoClassDefFoundError 怎么区分
名字像，但完全不是一回事：NoClassDefFoundError 是类加载失败（比如依赖缺失、静态块抛异常），而 InstantiationException 是类存在、可加载，但语义上不允许实例化。
关键判断点：
- 看异常栈里有没有
at java.lang.Class.newInstance或类似反射调用链 - 检查异常消息是否包含
can't instantiate interface或can't instantiate abstract class - 如果同一段代码在测试环境 OK、生产环境炸，大概率是
NoClassDefFoundError；如果本地跑起来就炸，且明确指向某个抽象类，基本就是InstantiationException
性能影响：两者都不影响正常执行流，但 InstantiationException 是明确的设计约束，捕获它通常意味着逻辑缺陷，不该靠 try-catch 吞掉，而应修复实例化路径。
Spring/MyBatis 等框架里怎么避免这个错
框架底层大量用反射，但它们自己会做类型检查。问题往往出在配置写错了，或者自定义扩展时没遵循约定。
常见场景与对策：
- Spring
@Configuration类里@Bean方法返回抽象类？不行。要么改成返回具体子类，要么用@Scope("prototype")+ 工厂方法 - MyBatis 的
resultType写成接口？会报InstantiationException。必须指定具体实现类，或改用resultMap手动映射 - Lombok 的
@Data加在抽象类上？没问题；但如果你又写了new AbstractEntity()，那就是你的问题 - 使用 Jackson 反序列化 JSON 到接口？需要注册
SimpleModule添加子类型映射，否则也会在内部反射时报这个错
最容易被忽略的一点：IDE 自动补全有时会把抽象类名塞进 new 表达式，尤其是继承体系深的时候——别光看语法高亮绿了就以为对了，得确认那个类是不是真能 new。
