Java中抽象类通过模板方法模式固定业务骨架：用public final模板方法锁死流程顺序，内部依次调用具体方法（复用）、抽象方法（强制实现）和钩子方法（可选覆盖）。
在 Java 中，抽象类通过模板方法模式固定整体业务骨架，核心是“把不变的流程锁死，把可变的逻辑留白”。关键不在写多少代码，而在怎么划分责任——哪些必须一致、哪些允许不同、哪些可以忽略。
用 final 修饰模板方法，封住调用顺序
模板方法本身必须声明为 public final，这是骨架稳定的前提。一旦子类能重写它，整个流程就可能被跳过、颠倒或重复执行。
- 模板方法内部按真实执行顺序依次调用各步骤，比如：
validate() → process() → persist() → notify() - 每个步骤可以是具体方法（父类已实现）、抽象方法（子类必须实现）或钩子方法（子类可选覆盖）
- 客户端只接触这个 final 方法，不感知内部结构，也不需要知道子类做了什么
把稳定环节抽成具体方法，复用不重复
所有子类都一致的逻辑，直接在抽象类里写成普通方法，比如参数校验、日志记录、事务控制、结果封装等。
- 例如：
checkPermission()统一查用户权限，wrapResponse()统一封装返回格式 - 这些方法默认被模板方法调用，子类无需重写，也不建议重写（除非有极特殊需求）
- 避免每个子类都 copy-paste 一段相同的校验或日志代码
把差异环节声明为 abstract 方法，强制子类填空
业务中真正因场景而异的部分，比如库存扣减方式、价格计算规则、通知渠道选择，应定义为 protected abstract 方法。
- 子类继承后必须实现这些方法，否则编译不通过
- 这样既保证了流程完整性，又让每个子类只专注自己那块逻辑
- 比如秒杀订单重写
deductStock()走 Redis 原子操作，普通订单则走 MySQL 行锁更新
用钩子方法支持柔性干预，不破坏主干
有些环节不是“必须有”，而是“可能需要”。比如“金额超 500 元触发人工审核”，这种条件性步骤适合用钩子方法。
- 在抽象类中定义：
protected boolean shouldTriggerReview() { return false; } - 模板方法中写：
if (shouldTriggerReview()) doExtraReview(); - 只有高风险子类才重写该钩子并提供
doExtraReview()实现，其他子类完全不用管
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
