抽象方法的核心特点是只声明行为契约、无方法体、编译期强制子类实现；它必须以分号结尾，禁止大括号和任何实现代码，且只能出现在抽象类或接口中，不可用private、static、final修饰。
Java 中抽象方法的核心特点是：它只声明行为契约，不提供具体实现，且编译器强制子类必须覆盖——正因如此，它绝不能有方法体。
抽象方法必须没有方法体
抽象方法的声明以分号结尾，禁止出现大括号 {} 和任何实现代码。哪怕只写一个空语句或 return;，也会触发编译错误：abstract methods cannot have a body。
-
合法写法：
public abstract void save(); -
非法写法：
public abstract void save() {}或public abstract void save() { return; }或public abstract void save() { throw new UnsupportedOperationException(); }
这不是风格问题，而是 JVM 规范层面的硬性约束：一旦有了方法体，它就不再是“待实现”的抽象方法，而变成普通方法或默认方法，语义彻底改变。
抽象方法只能出现在抽象类或接口中
它不能独立存在，也不能定义在普通类里。如果一个类包含至少一个抽象方法，这个类就必须用 abstract 修饰；否则编译直接失败。
立即学习“Java免费学习笔记（深入）”；
- 抽象类中可同时包含抽象方法和非抽象方法（如工具方法、模板逻辑）
- 接口中的抽象方法默认就是
public abstract，修饰符可省略，但依然不可写方法体 - 抽象方法不能是 private（子类不可见）、static（不参与多态）、final（禁止重写）——这些修饰符与“强制子类实现”的设计目标冲突
抽象方法的本质是编译期契约
它不是为了“占位”或“临时留空”，而是向编译器发出明确信号：该方法的行为必须由具体子类决定。这种约束发生在编译阶段，而非运行时。
- 若子类不是 abstract，却未实现父类所有抽象方法，编译器报错：must either be declared abstract or implement abstract method
- 若子类选择不实现，它自己也必须声明为 abstract，把实现责任继续向下传递
- 这种机制确保只要代码能通过编译，就说明所有抽象契约已被履行——避免了运行时才发现缺失逻辑的隐患
为什么不用空方法体代替抽象方法
有人会想：“我写个 public void save() {} 不也一样？子类可以重写。”但这样无法达到抽象方法的设计目的：
- 空方法体是可选覆盖，子类可能完全忽略，编译器不检查
- 抽象方法是强制覆盖，漏掉一个就编译失败，从源头杜绝误用
- 它表达的是“这个能力必须由你定义”，而不是“这个能力我先随便给个空壳”
抽象方法的存在，是为了让类的设计意图清晰、调用边界明确、继承关系可靠——它不是语法限制，而是面向对象建模中对“职责分离”和“契约保障”的落地支持。
