abstract方法必须由子类实现，因为编译器在编译期强制校验非抽象子类必须重写所有父类abstract方法，否则编译失败；它定义“做什么”而非“怎么做”，配合模板方法可约束核心流程与可变环节。
为什么 abstract 方法必须由子类实现
Java 的 abstract 方法没有方法体，编译器会在子类继承时强制校验：如果子类不是 abstract 类，就必须重写所有父类的 abstract 方法。这是编译期检查，不是运行时提示——没实现就编译失败，根本跑不起来。
关键点在于：抽象方法只定义“要做什么”，不关心“怎么做”。业务核心逻辑（比如支付、审批、解析）恰恰需要子类根据具体场景决定实现细节，这时候用 abstract 方法是最直接的契约约束。
- 子类是
final或普通类 → 必须实现所有abstract方法 - 子类自己也是
abstract类 → 可选择性实现，但最终非抽象子类仍需补全 - 接口不能替代这个场景：接口无法提供默认流程骨架（比如模板方法中的预处理/后置动作），而抽象类可以
用模板方法模式组合 abstract + 普通方法
光靠 abstract 方法只能卡住入口，没法控制执行顺序。真正落地时，90% 的业务抽象类会配合模板方法（Template Method）：把不变的流程写死在 final 方法里，把可变环节声明为 abstract 方法留给子类填空。
例如一个订单处理抽象类：
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
public abstract class OrderProcessor {
// 模板方法：不允许子类覆盖
public final void process() {
validate();
executeCore(); // ← 抽象方法，子类必须实现
notifySuccess();
}
<pre class="brush:php;toolbar:false;">private void validate() { /* 公共校验逻辑 */ }
private void notifySuccess() { /* 统一通知 */ }
protected abstract void executeCore(); // 核心业务逻辑，强制实现}
-
process()是公开入口，final保证流程不被破坏 -
executeCore()是钩子，子类只需关注自己的那一段逻辑，不用操心调用时机 - 如果子类误删了
executeCore()实现，编译直接报错：class XXX must either be declared abstract or implement abstract method executeCore() in OrderProcessor
abstract 类中混用普通字段和 abstract 方法的风险
抽象类可以有实例字段，但要注意初始化时机。如果子类构造器还没跑完，抽象方法就被模板方法提前调用（比如在父类构造器里），会导致 NullPointerException 或未定义行为——因为子类字段还没初始化。
- 避免在抽象类构造器中调用
abstract方法 - 不要在
abstract方法实现中直接访问子类未初始化的字段 - 字段尽量用
protected+final或通过构造器传参注入，而非依赖子类重写 setter - 常见错误现象：
java.lang.NullPointerException出现在抽象父类的方法栈里，但实际是子类字段为null
当需要“部分强制实现”时怎么设计
不是所有核心逻辑都要求 100% 强制。比如日志记录、降级策略这类可选能力，可以用 protected 空方法代替 abstract 方法，让子类按需覆盖：
protected void onFallback() {
// 默认什么都不做，子类可选择重写
}- 想强制实现 → 用
abstract void xxx() - 想允许跳过 → 用
protected void xxx() { } - 想提供默认行为 → 用
protected void xxx() { /* 默认实现 */ } - 注意：空方法体不等于无成本，JVM 仍会生成字节码，高频调用时建议加
if (isFallbackEnabled())条件判断
抽象类的约束力来自编译器，但它的真正价值不在“能不能绕过”，而在于让团队在写子类时，一眼看出哪些方法是业务主干、不能删减，哪些是锦上添花、可选扩展。这点比文档或注释靠谱得多。
