抽象方法的核心作用是建模“共性行为但实现各异”的逻辑，强制子类提供具体实现，从而统一接口、支撑多态、保障扩展一致性；它无方法体，必须在abstract类或interface中声明，子类继承后未实现则编译报错。
抽象方法的核心作用是建模“共性行为但实现各异”的逻辑，强制子类提供具体实现，从而统一接口、支撑多态、保障扩展一致性。
抽象方法本质是行为契约
它不关心“怎么做”，只规定“必须有这个能力”。比如所有图形都要能算面积，但圆用 πr²、矩形用长×宽——抽象方法 calculateArea() 就是这个统一入口，子类各自填空。
- 没有方法体（只有分号，无
{}） - 必须出现在 abstract 类或 interface 中
- 子类继承后不实现 → 编译报错（除非子类也声明为 abstract）
它解决的是设计层面的不确定性
父类知道“该有这个功能”，但无法预设实现细节。例如“动物叫”：狗叫汪汪、猫叫喵喵、鸟叫啾啾——抽象方法 makeSound() 把这种不确定性显式表达出来，把具体决策权交给子类。
- 避免父类写一个“假实现”（比如空方法体或抛异常），让调用方困惑
- 防止子类遗漏关键行为（编译期就拦截，不是运行时才发现缺功能）
- 让继承关系更语义清晰：“Animal”本就不能实例化，它只是概念容器
它是多态落地的关键支点
有了抽象方法，才能用父类类型变量指向不同子类对象，并在运行时自动调用对应实现：
Animal a1 = new Dog(); a1.makeSound(
); // 输出“汪汪汪”
Animal a2 = new Cat(); a2.makeSound(); // 输出“喵喵喵”- 调用方只依赖
Animal和makeSound()签名，完全不用知道背后是哪个子类
它和抽象类一起构成可演进的模板结构
抽象方法不能单独存在，必须依托抽象类（或接口）。这个组合相当于一份“半成品设计蓝图”：
- 抽象类提供共用字段、构造器、已实现的工具方法（如日志、校验）
- 抽象方法划出必须覆盖的“功能边界”
- 新增子类只需专注实现差异部分，无需改动已有结构
基本上就这些。
