抽象类的核心价值在于组织可复用、可扩展的代码结构，典型体现为模板方法模式：父类定流程（final模板方法）、子类填细节（抽象方法），辅以钩子方法提供可选扩展点，避免滥用为接口或大杂烩。

抽象类的核心价值不在“抽象”本身，而在它如何组织可复用、可扩展的代码结构。模板方法模式正是抽象类最典型、最有力的落地方式——用父类定流程，子类填细节。

抽象类不是为了“不能实例化”，而是为了定义骨架

抽象类本质是“部分实现的类”。它允许你把固定不变的逻辑（比如日志记录、资源准备、异常兜底）写在父类里，同时留出几个关键步骤让子类决定怎么干。

例如一个报表导出功能：

• 统一的开始时间记录、数据校验、文件命名规则、结束日志——这些写在抽象类的具体方法中
• “查什么数据”“按什么格式组装”“存到哪里”——这些声明为抽象方法，由 ExcelReport、PdfReport 等子类各自实现

模板方法必须用 final 修饰，否则骨架就塌了

模板方法（比如 export()）是算法的总控入口，它的执行顺序不能被子类改动。一旦子类重写了它，就可能跳过校验、绕过日志，破坏整体一致性。

正确写法：

• public final void export() { prepare(); fetchData(); format(); save(); cleanup(); }
• 其中 fetchData() 和 format() 是 protected abstract 方法
• prepare() 和 cleanup() 是已实现的具体方法

钩子方法（Hook）让子类有“选择权”，而不是“强制权”

不是所有扩展点都需要子类必须实现。有些步骤是可选的，比如“导出前是否弹窗确认”“失败后是否自动重试”。这时用钩子方法更自然：

• 在抽象类中提供一个空的 protected void beforeExport() {}
• 子类按需覆盖，不覆盖就什么也不发生
• 模板方法里调用它：beforeExport(); —— 不影响主流程，又保留灵活性

别把抽象类当接口用，也别让它变成“大杂烩”

抽象类可以有构造器、字段、private 方法、静态工具方法，但不代表应该全塞进去。

• 构造器只用于初始化共用状态（如配置对象、连接池引用）
• 字段尽量设为 protected 或 private + protected getter，避免子类随意修改内部状态
• 避免在抽象类里放业务无关的工具方法（比如字符串处理），应抽到独立工具类
• 如果发现抽象类里90%都是具体实现，只剩1个抽象方法——该考虑是不是设计反了，或者其实更适合用策略模式