抽象类有构造方法但不能实例化，因其设计目的是被继承而非直接使用；构造方法供子类通过super()调用以初始化共用状态，而实例化被编译器在语法层面禁止，确保子类补全抽象方法后才形成完整类型。
抽象类有构造方法，但不能 new 出对象，这看似矛盾，其实反映的是“初始化能力”和“完整定义能力”的分离。
构造方法是为子类服务的
抽象类的构造方法不会被直接调用，而是在子类创建实例时，由子类构造器通过 super() 隐式或显式触发。它的作用是初始化父类中定义的字段或执行共用的初始化逻辑。
- 比如 Animal 是抽象类，含
protected String name;和构造方法Animal(String name) - 子类 Dog 的构造器里必须处理
name，通常写成super(name) - 若 Animal 只有带参构造，而 Dog 构造器没写
super(...)，编译直接报错
无法实例化是编译期强制规则
Java、C#、C++ 等语言在编译阶段就禁止对抽象类使用 new。这不是运行时检查，也不抛异常，而是语法层面的硬性限制。
- 只要类被声明为 abstract，或含有未实现的抽象方法（C++ 中是纯虚函数），它就被视为“不完整类型”
- 即使这个抽象类一个抽象方法都没有，仅靠
abstract关键字修饰，也不能实例化 - 编译器拒绝生成该类的对象布局信息，因为缺少可确定的行为契约
抽象性 ≠ 无意义，而是“待补全”
抽象类不是残缺的代码，而是有意留白的设计。它像一份带组装说明的图纸——构造方法就是那本说明书，但图纸本身不是成品机器。
- 它封装了共用状态（如字段）、共用行为（如非抽象方法）、以及必须由子类回答的问题（抽象方法）
- 子类继承它，填上抽象方法的具体实现，才构成一个“能独立存在、行为明确”的具体类型
- 这种机制保障了多态安全：所有子类对象都满足父类约定，调用抽象方法时绝不会落空
常见误解澄清
有人以为“有构造方法就能 new”，这是把两个正交概念混在一起了。能否构造，取决于有没有初始化逻辑；能否实例化，取决于是否具备全部可执行行为。
- 接口没有构造方法，也不能实例化——但原因不同：它连字段和初始化逻辑都不提供
- 普通类有构造方法，也能实例化——因为它已承诺提供所有方法的实现
- 抽象类有构造方法，但不能实例化——因为它主动声明：“我还缺几块拼图，请子类来补”
