抽象类不能直接实例化，根本原因是Java编译器在语法层面禁止——只要类被abstract修饰或含抽象方法，new操作就在编译期报错；这是编译期硬性限制，而非运行时检查。
抽象类不能直接实例化，根本原因不是它“少了实现”，而是 Java 编译器在语法层面就禁止这种操作——只要类被 abstract 修饰，或者包含未实现的抽象方法，new Xxx() 就会在编译期报错：“Cannot instantiate the type Xxx”。
这是编译期的硬性语义限制
Java 把 abstract 当作一种类型完整性声明：它明确告诉编译器，“这个类不完整，不能独立存在”。编译器据此拒绝生成该类的实例结构（比如对象头、字段布局、虚方法表等），也不允许生成调用其构造器的字节码。这不是运行时检查，更不是靠抛异常拦截，而是从源头上不让代码通过编译。
抽象方法的存在要求行为必须可确定
JVM 执行方法调用时，必须能定位到具体字节码。抽象方法只有声明、没有实现，意味着调用它将无处执行。如果允许实例化含抽象方法的类，就会出现“对象能创建，但一调方法就崩溃”的矛盾。因此语言强制规定：含抽象方法 → 必须声明为 abstract → 自动禁止实例化。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
构造方法存在，不代表能 new
抽象类可以有构造方法，甚至可以是 public，但这只为子类服务。子类构造时，会通过 super(...) 显式或隐式调用父类构造逻辑，完成字段初始化、参数校验等。这个过程由 JVM 在创建子类对象时自动触发，和“直接 new 抽象类”完全无关。
立即学习“Java免费学习笔记（深入）”；
和接口的禁止逻辑一致，但机制不同
接口也不能实例化，但它连构造方法都不允许定义——因为接口不承载状态，只定义契约。抽象类则不同：它既承载状态（字段）、又封装部分行为（具体方法），只是主动留白关键行为（抽象方法）。两者都被禁止实例化，本质都是为了保障多态安全：确保任何向上转型后的调用，都有真实可执行的逻辑支撑。
