Java抽象类的设计初衷是实现部分实现与强制继承的统一：它既封装共用状态和逻辑，又通过抽象方法强制子类实现特定行为，填补普通类与接口之间的关键空白。
Java抽象类的设计初衷，是为了解决“既要复用代码，又要强制规范行为”这一现实矛盾。它不是为了替代普通类或接口，而是填补两者之间的关键空白：一个不能被直接创建的对象模板，既承载状态和通用逻辑，又留下必须由子类填充的空白。
核心设计初衷：部分实现 + 强制继承
当多个类属于同一概念范畴（如“动物”“图形”“支付方式”），它们天然共享属性（如name、color）、通用行为（如breathe()、printInfo()），但某些关键行为（如makeSound()、area()）又必须因具体类型而异时，抽象类就成为最自然的选择。
- 它用构造方法支持子类初始化共用状态，这是接口做不到的
- 它用普通方法封装可复用逻辑，避免子类重复编写
- 它用抽象方法划出“必答题”，编译器会强制子类完成，保障设计完整性
典型使用场景：看这三类情况是否同时出现
遇到以下任意一种组合，抽象类往往比接口或普通类更合适：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
有共同状态需要初始化：比如所有图形都有
color和borderWidth，且需在创建时传入——抽象类可定义带参构造器，子类通过super()统一初始化 -
存在固定流程+可变步骤：比如游戏启动流程总是
initialize → startPlay → endPlay，但每种游戏的初始化方式不同——抽象类可用final模板方法封装骨架，只把initialize()声明为抽象 - 需要表达明确的“is-a”关系：Dog is-a Animal，Rectangle is-a Shape——这种血缘式继承强调本质归属，适合用抽象类；而Flyable、Serializable这类能力契约，则属于接口范畴
和接口的关键分界点：别混淆“是什么”和“能做什么”
一个类只能继承一个抽象类，却能实现多个接口。这意味着：
立即学习“Java免费学习笔记（深入）”；
- 如果关注的是“它本质上属于哪一类”，比如所有子类都应继承
Vehicle并共享fuelLevel字段和refuel()逻辑，那就用抽象类 - 如果关注的是“它额外具备什么能力”，比如
Drivable、Autonomous、Electric可以叠加在不同类上，那就用接口 - 现实中常混合使用：
class Tesla extends Vehicle implements Drivable, Autonomous
实际编码中容易忽略的细节
抽象类不是语法糖，它的约束力体现在编译期：
- 子类若未实现全部抽象方法，且自身未声明为
abstract，编译直接报错 - 抽象方法不能是
private、static或final——否则子类无法重写 - 抽象类可以没有抽象方法（极少用），但只要有抽象方法，类就必须声明为
abstract - 构造方法虽不能用于实例化，却是子类
super()调用的唯一入口，用于设置父类字段
