Java抽象类通过编译期强制校验确保非抽象子类实现全部抽象方法；抽象方法仅声明签名，子类若非abstract则必须@Override实现，否则编译失败；子类可选成为abstract以延迟实现；模板方法用final方法固定流程、抽象方法作钩子；构造器中调用抽象方法易致NullPointerException。
Java 抽象类通过 编译期强制校验 来确保非抽象子类必须实现所有抽象方法——没写完就编译失败，根本跑不起来。
抽象方法定义行为契约
抽象方法只声明签名（名称、参数、返回值），不提供实现体。它相当于一份“必须完成的任务清单”：
- 用
abstract关键字修饰，不能加private、final或static - 子类若不是
abstract类，就必须用@Override实现每一个抽象方法 - 漏掉一个，编译器直接报错：class XXX must either be declared abstract or implement abstract method ...
- 例如：
public abstract double getArea();要求所有图形子类自己写出面积怎么算
子类继承时的两种合法路径
抽象类不强迫“立刻完工”，但会盯住最终结果：
- 子类是普通类（非
abstract）→ 必须全部实现父类抽象方法 - 子类自己也声明为
abstract→ 可以只实现部分，甚至一个都不实现；但它的子类仍得继续补全 - 这种“延迟实现”适合多层抽象，比如
Shape → TwoDimensionalShape → Circle
配合模板方法控制执行逻辑
光有抽象方法只能卡住“有没有实现”，真正落地还要管“什么时候调用”。这时靠模板方法模式：
立即学习“Java免费学习笔记（深入）”；
- 在抽象类中写一个
final方法（如process()），固定流程顺序 - 把可变环节抽成抽象方法（如
executeCore()），作为“钩子”留给子类填空 - 子类无法修改流程，又逃不开实现核心逻辑——删掉
executeCore的实现，照样编译不过
注意构造器里别调用抽象方法
这是容易踩的坑：如果在抽象类构造器中就调用了某个 abstract 方法，而子类字段还没初始化，运行时可能出 NullPointerException：
- 抽象类构造器先执行，此时子类构造逻辑尚未开始
- 抽象方法被调用，实际执行的是子类重写版本，但子类字段仍是默认值（如
null或0） - 所以设计上要避免在构造过程中依赖子类状态
