abstract修饰类时必须满足：该类不能被实例化，且至少有一个子类（该子类须为abstract或实现全部抽象方法）。
abstract修饰类时必须满足什么条件
Java里用abstract修饰的类不能被实例化，这是最核心的限制。如果你写了new AbstractClass()，编译器会直接报错：Cannot instantiate the type AbstractClass。
抽象类存在的意义是被继承，所以它至少得有一个子类——而且这个子类要么也声明为abstract，要么必须重写所有未实现的抽象方法。
- 抽象类可以包含普通方法、构造方法、静态方法、字段（包括
private字段） - 抽象类的构造方法不是用来创建对象的，而是供子类调用，完成初始化逻辑
- 抽象类可以不包含任何
abstract方法（虽然少见，但合法）
abstract方法只能出现在哪些地方
abstract方法只能定义在abstract类或interface中。如果把它写在普通类里，编译直接失败：Abstract method in non-abstract class。
抽象方法没有方法体，以分号结尾，且不能用private、static、final修饰（这些修饰符和“强制子类覆盖”的语义冲突）。
立即学习“Java免费学习笔记（深入）”；
- 抽象方法可以有访问修饰符：
public、protected（默认包级可见也允许） - 接口中的方法默认就是
public abstract，即使不写这两个关键字 - 抽象类中非抽象方法可以调用抽象方法（由子类实现后实际执行）
子类继承abstract类时容易漏掉什么
最常见的错误是：子类没加abstract，又没实现父类的所有抽象方法，结果编译不过，报错信息类似：must either be declared abstract or implement abstract method 'xxx()' in 'XXX'。
尤其当父类新增了一个抽象方法，而你忘了同步更新所有子类时，这种问题会在编译期暴露，但容易被忽略——因为IDE可能只高亮当前文件，不提示其他子类。
- 使用
@Override标注重写的方法，能避免拼写错误导致的“看似重写实则新增” - 如果子类只是临时不想实现某个抽象方法，就老老实实加上
abstract修饰，并确保自己也不被实例化 - 抽象类的子类如果是
final的，那它必须实现全部抽象方法（否则矛盾）
abstract类和interface在设计意图上的关键区别
这不是语法题，而是建模选择：抽象类强调“是什么”，interface强调“能做什么”。比如Animal适合抽象类（有共用字段如name、共用逻辑如breath()），而Flyable适合接口（飞行行为跨物种，鸭子、飞机、无人机都可能实现）。
Java 8之后接口支持default和static方法，模糊了部分边界，但抽象类仍保留着唯一优势：可以有构造器、可以有protected成员、可以持有状态（非静态字段）。
- 一个类只能继承一个抽象类，但可以实现多个接口
- 抽象类中的
protected方法可被子类直接调用；接口无法提供这种受控的内部复用能力 - 如果未来可能需要添加带状态的模板逻辑，优先选抽象类；如果只是契约声明，接口更轻量
抽象类不是“半成品类”，它是有意留白的设计契约。真正容易出问题的地方，往往不在定义时，而在后续扩展——比如给抽象类加新抽象方法，却忘了检查所有继承链是否完整。这种破坏性变更，比改接口更隐蔽。
