抽象类不能被new是Java强制设计约束，因其行为不完整（含未实现抽象方法），编译时即报错；应改用具体子类（如new Dog()）、工厂模式或依赖注入获取实例。
抽象类不能被 new 实例化，不是 bug，而是 Java 的强制设计约束——它本就不该被直接创建对象。解决方向不是“绕过限制”，而是回归抽象类的设计本意：作为模板被继承、被实现。
为什么抽象类不能 new
抽象类缺少完整行为定义，可能含未实现的抽象方法，或仅用于统一结构与共享逻辑。JVM 在字节码验证阶段就禁止实例化，编译时 new Animal() 就会报错：“Animal is abstract; cannot be instantiated”。接口同理，它连构造器都没有，根本无法初始化状态。
正确获取可用对象的三种方式
你需要的不是一个抽象类的实例，而是一个符合该契约的具体对象：
- 用它的非抽象子类直接 new：比如
new ArrayList()替代new List()，new Dog()替代new Animal()（前提是Dog继承Animal并实现了全部抽象方法） - 通过工厂封装选择逻辑：根据业务参数返回不同子类实例，避免到处硬编码
new ConcreteXxx() - 交给 Spring 等容器管理：用
@Service标记具体实现类，再通过接口类型注入，让框架自动选型
动态场景下必须提前校验
反射、JSON 反序列化、MyBatis resultType 等运行时创建对象的场景，最容易在启动或执行时抛 InstantiationException。不能靠 try-catch 补救，而应在创建前主动检查：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 用
clazz.isInterface()判断是否为接口 - 用
Modifier.isAbstract(clazz.getModifiers())判断是否为抽象类 - 校验通过后再调用
getDeclaredConstructor().newInstance()，否则明确提示“请提供具体实现类”
设计时就该想清楚：用抽象类还是接口
抽象类适合表达“是什么”+“有共性实现”：
- 需要定义 protected 字段、构造器初始化、共享方法逻辑（如通用校验、日志模板）
- 子类天然具备 is-a 关系（如
Cat extends Animal） - 未来可能增加默认行为，又不希望破坏现有子类
接口更适合定义“能做什么”，支持多实现、更轻量，但无法持有状态或提供构造逻辑。
