抽象方法不能有方法体，因为编译期禁止大括号和实现逻辑，JVM要求其无具体实现，否则报错；子类若不实现所有抽象方法，自身必须声明为abstract，否则编译失败；抽象方法是编译期强制契约，优于运行时抛异常的软性模拟。
抽象方法为什么不能有方法体
因为 abstract 修饰的方法在编译期就明确禁止写大括号和实现逻辑。JVM 规范要求抽象方法必须无具体实现，否则编译直接报错：Illegal combination of modifiers: abstract and final（如果误加 final）或更常见的 abstract methods cannot have a body。
这不是语法糖，是语言层面的契约设计：抽象方法只声明“做什么”，不规定“怎么做”。一旦写了方法体，它就不再是抽象的，也不再能被子类强制重写——这就破坏了抽象类作为模板的核心作用。
- 你写
public abstract void run();✅ 合法 - 你写
public abstract void run() { System.out.println("x"); }❌ 编译失败 - 哪怕只写一个分号结尾（
public abstract void run();）也必须省略花括号
子类不实现抽象方法会怎样
子类如果不实现所有继承来的抽象方法，那它自己也必须声明为 abstract；否则编译器会拒绝通过，并提示类似错误：class X must either be declared abstract or implement abstract method Y in Z。
这个检查发生在编译阶段，不是运行时。也就是说，只要代码能编译过，就说明所有抽象方法已被满足——要么由当前类实现，要么当前类放弃实例化资格，继续当抽象类。
立即学习“Java免费学习笔记（深入）”；
- 普通子类（非
abstract）→ 必须重写全部抽象方法 - 抽象子类 → 可选择性实现部分抽象方法，剩余留给更下层子类
- 接口中的默认方法（
default）不影响此规则，它们不算抽象方法
抽象方法和接口方法的区别在哪
Java 8 之后，接口也能有 default 和 static 方法，但 abstract 方法在接口里仍是默认修饰符（可省略），且仍不可有方法体。关键差异不在语法，而在语义约束：
- 抽象类里的抽象方法可以有
protected、public修饰符；接口中所有抽象方法自动是public abstract，不能改 - 抽象类可以有字段、构造器、非抽象方法；接口不能有实例字段（只有
public static final常量）和构造器 - 一个类只能继承一个抽象类，但能实现多个接口——这意味着抽象方法的“强制实现”压力来源不同
比如你定义了 abstract class Animal { abstract void breathe(); }，子类必须实现 breathe()；而如果把它挪到接口里：interface Living { void breathe(); }，效果表面一样，但实现类可能同时还要实现 Runnable、Swimmable 等多个契约。
什么时候该用抽象方法而不是普通方法+抛异常
用 throw new UnsupportedOperationException() 模拟“未实现”是常见反模式。抽象方法的优势在于：提前暴露设计意图、编译期拦截、IDE 自动提示补全、重构安全。
- 运行时抛异常 → 错误延迟到第一次调用才暴露，测试覆盖不到位就容易漏
- 抽象方法 → 编译失败即知缺失，IDE 会高亮未实现方法，新建子类时自动弹出“Implement Methods”提示
- 性能上无差异，两者都不影响字节码执行效率，但抽象方法让类型系统真正参与约束
比如你在框架中定义模板流程：abstract class Processor { abstract void parse(); void execute() { parse(); doWork(); } }，比写成 void parse() { throw new UnsupportedOperationException(); } 更可靠——前者强迫使用者思考“怎么解析”，后者鼓励跳过。
真正在意的是契约是否被工具链识别。抽象方法是 Java 类型系统里少数几个能“把责任推给子类”的硬性机制，别用软性手段绕开它。
