抽象类在Java中核心是强制子类实现关键行为并复用通用逻辑。它通过abstract方法在编译期约束子类实现，支持字段共享、构造器逻辑和模板方法，但需避免滥用protected字段、模糊命名及过深继承链。
抽象类在 Java 中解决的核心问题是：**强制子类实现关键行为，同时复用通用逻辑**。它不是为了解耦或替代接口，而是为“有一部分代码大家都一样，但另一部分必须各自实现”这种场景提供语法支持。
抽象类 vs 普通父类：为什么不能只用继承？
普通父类可以复用代码，但无法约束子类必须重写某个方法——子类可能忘了实现关键业务逻辑，编译期零提示，运行时才出错。
抽象类通过 abstract 方法把“必须实现”的契约提前到编译阶段：
-
abstract void render();声明后，任何非abstract子类都必须提供具体实现，否则编译失败 - 子类仍可直接调用父类的非抽象方法（如
validateInput()、logStart()），无需重复写 - 抽象类本身不能被实例化，避免了“只new父类却没实现核心逻辑”的误用
抽象类 vs 接口：什么时候该选 abstract class？
当需要共享状态（字段）、复用带实现的方法、或构造器逻辑时，接口做不到，抽象类可以。
立即学习“Java免费学习笔记（深入）”；
典型场景包括：
- 多个子类共用同一套初始化流程（如数据库连接池配置、资源预加载），可在抽象类构造器中统一处理
- 子类需继承一个 protected 字段（如
protected Config config;），且该字段由父类构造器注入 - 已有方法体要复用，且其中调用了子类必须实现的钩子方法（模板方法模式）：
final void execute() { before(); doWork(); after(); }，其中doWork()是abstract
抽象类设计常踩的坑
抽象类容易被当成“半成品接口”滥用，导致后期难以维护：
- 过度使用
protected字段——破坏封装，子类随意修改父类状态，调试困难 - 抽象方法命名模糊，如
handle()，不说明上下文和契约，子类实现五花八门 - 在抽象类里写静态工具方法，混淆职责；应移入
Utils类 - 抽象类继承链过深（A → B → C → D），新增子类时要翻三层源码才能理解调用顺序
真正难的不是写 abstract class，而是判断哪些逻辑属于“所有子类必然共有”，哪些其实只是“当前恰好相同”。后者一旦变化，抽象类反而成了枷锁。
