抽象类的根本意义是解决复用代码与强制规范行为的矛盾，它禁止实例化、允许存状态、提供具体方法并强制子类实现抽象方法。
抽象类存在的根本意义，是解决“既要复用代码，又要强制规范行为”这一对矛盾——它不是为了炫技，而是为了解决你正在写的那个 Animal、Shape 或 DataProcessor 类里反复出现的现实困境。
为什么不能直接用普通类或接口代替？
你写了一个 Vehicle 类，想让 Car 和 Bike 都继承它，但立刻遇到三个卡点：
- 普通类允许
new Vehicle()—— 语义错误（现实中没有“一辆车”，只有“一辆宝马”或“一辆山地车”）； - 接口不能存
protected String brand这种状态字段，也无法提供startEngine()这种带公共逻辑的具体方法； - 如果只靠文档或约定要求子类必须实现
refuel()，编译器不会拦你，等运行时才发现漏写了，出问题才暴露。
抽象类把这三件事一次性收口：禁止实例化 + 允许存状态 + 提供具体方法 + 强制实现抽象方法。
什么时候该定义抽象类？看这三条硬标准
别凭感觉，用下面三个条件交叉判断——满足任意两条，就该上抽象类：
立即学习“Java免费学习笔记（深入）”；
- 多个子类共享同一组字段（比如
color、createdAt、id），且这些字段需要被子类直接访问（protected）； - 有一套固定流程，但其中某些步骤因子类而异（例如：数据库操作的
connect() → execute() → close()，只有execute()需要子类定制）； - 你希望所有子类对外暴露完全一致的方法签名（如都必须有
calculatePrice()），且这个行为无法在父类中给出通用实现。
反例：如果只是想声明“能排序”“能序列化”，用 Comparable 或 Serializable 接口更轻量；如果子类之间毫无状态或逻辑共性，强行抽抽象类反而增加维护成本。
抽象类里写构造方法，到底有没有用？
有用，而且很关键——它不是用来自己实例化的，而是给子类初始化用的。
abstract class Product {
protected final String sku;
protected final double basePrice;
// 构造方法会被子类的 super() 显式调用
protected Product(String sku, double basePrice) {
this.sku = sku;
this.basePrice = basePrice;
}
}
class Book extends Product {
private final String author;
public Book(String sku, double basePrice, String author) {
super(sku, basePrice); // ← 必须调用，否则编译报错
this.author = author;
}
}
常见坑：
- 忘了写
protected或public修饰符，导致子类无法访问构造方法； - 在抽象类构造器里调用抽象方法（
this.loadData()），此时子类对象尚未完成初始化，可能引发NullPointerException或未定义行为； - 误以为抽象类构造器可以被反射调用（
Class.getDeclaredConstructor().newInstance()），实际会抛InstantiationException。
抽象类和接口混用时，最容易忽略的边界
现代 Java 开发中，抽象类常和接口搭配使用，但边界必须划清：
- 用抽象类表达“是什么”（
is-a）：比如PaymentProcessor是一种支付处理器，它有retryCount状态、logError()通用逻辑； - 用接口表达“能做什么”（
can-do）：比如Refundable、AsyncCapable，这些能力可跨不同继承体系复用； - 别在抽象类里塞一堆
default方法去模拟接口行为——那说明你本该用接口；也别让抽象类实现太多接口，一旦它开始承担“行为契约”职责，就模糊了设计意图。
最常被跳过的细节：抽象类的字段默认不是 public static final，它可变、可继承、可被子类修改——这点和接口里的常量有本质区别。如果你需要的是不可变配置，请明确写成 public static final，而不是依赖抽象类“看起来像常量”的错觉。
