抽象方法的核心作用是建模“共性行为但实现各异”的逻辑，强制子类提供具体实现，从而统一接口、支撑多态、保障扩展一致性；它无方法体，必须在abstract类或interface中声明，子类继承后未实现则编译报错。

抽象方法的核心作用是建模“共性行为但实现各异”的逻辑，强制子类提供具体实现，从而统一接口、支撑多态、保障扩展一致性。

抽象方法本质是行为契约

它不关心“怎么做”，只规定“必须有这个能力”。比如所有图形都要能算面积，但圆用 πr²、矩形用长×宽——抽象方法 calculateArea() 就是这个统一入口，子类各自填空。

• 没有方法体（只有分号，无 {}）
• 必须出现在 abstract 类或 interface 中
• 子类继承后不实现 → 编译报错（除非子类也声明为 abstract）

它解决的是设计层面的不确定性

父类知道“该有这个功能”，但无法预设实现细节。例如“动物叫”：狗叫汪汪、猫叫喵喵、鸟叫啾啾——抽象方法 makeSound() 把这种不确定性显式表达出来，把具体决策权交给子类。

• 避免父类写一个“假实现”（比如空方法体或抛异常），让调用方困惑
• 防止子类遗漏关键行为（编译期就拦截，不是运行时才发现缺功能）
• 让继承关系更语义清晰：“Animal”本就不能实例化，它只是概念容器

它是多态落地的关键支点

有了抽象方法，才能用父类类型变量指向不同子类对象，并在运行时自动调用对应实现：

• Animal a1 = new Dog(); a1.makeSound(); // 输出“汪汪汪”
• Animal a2 = new Cat(); a2.makeSound(); // 输出“喵喵喵”
• 调用方只依赖 Animal 和 makeSound() 签名，完全不用知道背后是哪个子类

它和抽象类一起构成可演进的模板结构

抽象方法不能单独存在，必须依托抽象类（或接口）。这个组合相当于一份“半成品设计蓝图”：

• 抽象类提供共用字段、构造器、已实现的工具方法（如日志、校验）
• 抽象方法划出必须覆盖的“功能边界”
• 新增子类只需专注实现差异部分，无需改动已有结构

基本上就这些。