模板方法模式通过抽象基类固定算法骨架：父类用final execute()控制流程顺序，封装公共逻辑；子类仅实现abstract方法处理差异逻辑，并可选择性覆盖空钩子方法扩展行为。
在设计框架基类时，用模板方法模式固定算法骨架，核心是让父类掌控流程顺序、子类只负责填空。不是把逻辑全写死，也不是放任子类随意改流程——而是用抽象类划清“谁管什么”：父类锁住骨架，子类实现细节。
用 abstract 类定义骨架，模板方法必须加 final
框架基类一定是抽象类，里面声明一个 public final void execute()（或类似命名）作为唯一入口。这个方法里按真实执行顺序调用各步骤，比如：
- validateInput()
- prepareContext()
- doCoreWork() —— 抽象方法
- postProcess() —— 钩子方法
- logResult()
final 是硬性要求。一旦允许子类重写 execute()，就等于把控制权交出去了，框架的稳定性立刻崩塌。
把稳定环节直接实现在父类，不留给子类碰
那些所有子类都一致的动作，比如参数校验、上下文初始化、日志记录、异常包装、结果统一封装，全部写成父类里的具体方法。子类既不能重写，也不该关心——它们只是被模板方法自动调用的组件。
立即学习“Java免费学习笔记（深入）”；
例如：
protected void validateInput() { if (input == null) throw new IllegalArgumentException(); }
这种代码放在基类里，干净、统一、可维护。
差异逻辑拆成 abstract 方法，强制子类实现
真正因场景而异的部分，比如“怎么查库存”“怎么算价格”“用什么协议发通知”，必须声明为 protected abstract。这样编译器会强制每个子类提供自己的版本，避免漏实现。
- abstract void fetchResource();
- abstract Result transform(Data data);
- abstract void persist(Result result);
子类只需专注自己那一块，不用理解整个流程怎么串起来。
用空钩子方法支持柔性扩展，不破坏契约
有些步骤不是“必须有”，而是“可能需要”。比如“是否触发人工复核”“失败后要不要重试”“是否上报监控”。这类逻辑适合做成带默认空实现的 protected 方法：
- protected boolean shouldTriggerReview() { return false; }
- protected void onExecutionFailure(Exception e) {}
子类按需覆盖，不覆盖就走默认逻辑。既保持接口稳定，又留出干预点，比抽象方法更轻量、更安全。
