抽象方法必须以分号结尾且无方法体，因其实质是声明契约而非提供实现；若含花括号或语句则编译报错，旨在强制子类重写、保障多态基础与设计意图。
因为抽象方法的本质是“声明契约”，不是“提供实现”。Java 语言在编译阶段就强制要求：只要加了 abstract 修饰符，就不能有方法体——连空大括号 {} 或一个分号结尾都不行，必须以分号 ; 直接结束。
抽象方法的语法边界非常严格
编译器会逐字检查，一旦发现 abstract 方法里出现以下任一情况，立即报错 abstract methods cannot have a body：
-
public abstract void doWork() {}→ 错误：写了空大括号 -
public abstract void doWork() { return; }→ 错误：写了花括号和语句 -
public abstract void doWork() { throw new UnsupportedOperationException(); }→ 错误：哪怕只是抛异常也不允许 -
public abstract void doWork();→ 正确：只有声明，无实现，结尾是分号
为什么设计成这样？
这不是限制，而是保障。抽象方法存在的意义，是告诉所有子类：“你必须自己定义这个行为”。如果允许写方法体，就会产生歧义：
- 子类可能直接继承该实现，绕过重写，违背“强制实现”的初衷
- 父类若提供了默认逻辑，那它更适合用 default 方法（接口中） 或 模板方法（抽象类中普通方法调用抽象钩子）
- JVM 需要在加载时明确区分“可直接调用”和“必须由子类填充”的方法，这是运行时多态的基础
常见误解与替代方案
有人想写“暂不支持”的占位逻辑，比如返回 null 或抛异常，但这是无效的。正确做法是：
立即学习“Java免费学习笔记（深入）”；
- 真需要默认行为 → 改用 接口 default 方法（Java 8+）
- 想保留扩展点 + 提供基础流程 → 在抽象类中写一个 final 普通方法，内部调用 abstract 方法（即模板方法模式）
- 仅作占位、无实际逻辑 → 就保持
public abstract void xxx();，让子类承担完整实现责任
子类不实现会怎样？
编译器会在编译期就拦截：
- 子类是普通类 → 必须 @Override 所有 abstract 方法，否则报错：must either be declared abstract or implement abstract method
- 子类也声明为 abstract → 可以只实现部分，把剩余抽象方法继续往下传
