抽象方法是编译期硬性契约，具体子类必须全部实现，否则编译失败；它无方法体、不可private/static/final，配合模板方法嵌入流程，确保规范落地。
抽象方法在Java继承中不是“建议”而是“硬性要求”——只要子类是具体类（非 abstract），就必须实现父类中所有未被实现的抽象方法，否则编译直接失败。它不靠运行时检查，也不靠文档提醒，而是在代码写完、还没运行前，就由编译器把关，确保行为契约落地。
抽象方法就是一份编译期签署的“行为合同”
它不提供实现，只定义签名：访问修饰符 + 返回类型 + 方法名 + 参数列表，后面直接分号结束，没有大括号，也没有任何逻辑。例如：
protected abstract String generateTraceId();public abstract BigDecimal calculateDiscount(Order order);
这个签名一旦出现在 abstract 类中，就等于告诉所有具体子类：“你必须按这个样子，交出一个能跑通的实现”。子类若漏掉、改参数、降访问权限（如 public → protected）、或返回类型不协变，都不算履约，编译器会报错：must either be declared abstract or implement abstract method...
约束力来自继承链的逐层累积与最终兑现
抽象方法的强制性不是点对点的，而是贯穿整条继承链：
- 父类 A 声明了
abstract void loadConfig() - 中间类 B 继承 A，但自己也声明为
abstract，可以不实现loadConfig - 最终的具体类 C 继承 B，就必须实现 A 中的
loadConfig（以及 B 新增的任何抽象方法）
也就是说，抽象方法可以“挂起”，但不能“消失”；约束可以延后，但必须由某个具体子类兜底完成。
配合模板方法，让强制约束真正服务业务流程
光有抽象方法只能卡住“有没有”，实际开发中更需要它嵌入稳定流程。典型做法是：
- 用
final方法封装主干逻辑（如事务开启、参数校验、日志记录、异常统一包装） - 把变化点抽成
protected abstract方法，比如buildRequest()、parseResponse() - 子类只专注填空，不用重复处理横切关注点
这样，抽象方法不再是孤立的接口，而是流程中不可跳过的“插槽”，既保障规范统一，又保留业务灵活性。
注意两个关键边界，避免契约失效或运行时崩溃
一是不能在抽象类构造器中调用抽象方法——此时子类字段尚未初始化，极易触发 NullPointerException；二是抽象方法不能用 private、static 或 final 修饰，否则语义冲突：前者子类不可见，后两者禁止重写，都违背“留给子类实现”的设计本意。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
