抽象类核心价值是定义共同契约与可复用骨架，强制统一结构并封装稳定逻辑；不一定含abstract方法；适合共享带状态的实现，优于接口的场景包括需protected成员、共享实例状态、融入继承链等。
抽象类在 Java 中不是为了“实现共享代码”的权宜之计，而是为了一组相关类定义**共同契约 + 可复用骨架**。它强制子类遵循统一结构，同时允许把稳定逻辑（比如通用校验、模板流程、默认行为）抽到父类里，避免重复写 if、log、validate() 这类代码。
抽象类必须包含至少一个 abstract 方法吗？
不一定。Java 允许定义没有抽象方法的抽象类——只要加了 abstract 修饰符，就不能被实例化。这种写法常见于：预留扩展点、禁止直接使用基类、或未来会添加抽象方法但当前先沉淀通用工具方法。
例如：
abstract class DataProcessor {
protected void logStart(String id) {
System.out.println("Processing " + id);
}
// 没有 abstract 方法，但不能 new DataProcessor()
}
注意：如果真想纯共享工具，优先考虑 final 工具类 + 静态方法；抽象类更适合有“继承关系语义”的场景。
立即学习“Java免费学习笔记（深入）”；
抽象类 vs 接口：什么时候该选抽象类？
当你要共享的是**带状态的实现逻辑**（比如成员变量、构造器初始化、非静态字段、部分完成的方法），而不是仅行为契约时，抽象类更合适。
- 需要定义
protected字段供子类访问？→ 抽象类支持，接口不行 - 子类共用同一个
Logger实例或连接池？→ 抽象类可在构造器中初始化，接口无法持有实例状态 - 已有类层级（如
Animal → Dog），且想插入公共中间层（如Mammal）？→ 抽象类可自然融入继承链，接口只能多实现 - 要提供默认实现但又不希望所有实现类都继承同一套逻辑？→ 接口的
default方法是公开的、不可protected，而抽象类的方法可以控制可见性
抽象类里怎么安全地共享初始化逻辑？
别在抽象类构造器里调用 abstract 方法——子类构造器还没跑完，字段可能为 null，极易触发 NullPointerException 或未定义行为。
推荐方式：
- 把初始化拆成两步：构造器只设基础字段，另用
init()模板方法（final修饰）驱动子类完成后续设置 - 用
protected的setup()方法由子类显式调用，避免隐式依赖 - 若必须在构造阶段完成，确保所有被调用的子类方法只读取
final字段或参数，不依赖子类未初始化的成员
反例（危险）：
abstract class Service {
private final String name;
Service() {
this.name = generateName(); // 调用 abstract 方法！
}
abstract String generateName(); // 子类实现时可能访问未初始化字段
}
抽象类的泛型设计容易踩哪些坑？
泛型抽象类本身没问题，但要注意子类继承时类型擦除带来的限制：
- 子类继承
AbstractHandler后，不能再覆盖成handle(Integer)——JVM 看不到泛型，方法签名会冲突 -
getClass().getTypeParameters()在运行时拿不到具体类型，反射获取泛型信息需通过子类的getGenericSuperclass() - 不要在抽象类里对泛型参数做
instanceof判断（编译不过），改用传入Class参数或策略对象
典型安全写法：
abstract class Repository{ private final Class entityClass; protected Repository(Class entityClass) { this.entityClass = entityClass; } public T findById(long id) { return loadFromDb(id, entityClass); // 利用 Class 对象绕过擦除 } abstract T loadFromDb(long id, Class cls); }
抽象类的价值不在“能写代码”，而在“让代码不得不按你设想的方式生长”。一旦开始设计，就要想清楚：哪些逻辑是所有子类必然共有的？哪些字段是它们天然共享的状态？哪些方法必须由子类决定，但调用时机和上下文必须统一？这些才是抽象类真正发力的地方。
