模板方法模式必须用抽象类而非接口实现，核心是父类固化流程骨架、子类实现具体步骤；关键方法需final防篡改，protected abstract定义可变步骤，钩子方法提供可选扩展，且需注意线程安全与执行时机。
模板方法模式的核心是抽象类定义流程骨架
Java里用模板方法模式，本质就是让抽象类把「不变的执行顺序」写死，把「可能变化的步骤」留给子类去实现。不是靠接口，也不是靠普通父类——必须是 abstract class，且关键流程方法得是 final 或至少不被重写。
常见错误是：把整个流程逻辑放在子类里，只抽一个空方法出来；或者把模板方法本身设为 abstract，结果子类反而要重复写调用顺序——这就完全违背了“控制权在父类”的设计初衷。
-
templateMethod()必须是非抽象、非 private、通常为final（防子类篡改流程） - 被延迟到子类实现的方法，统一用
protected abstract修饰 - 可选钩子（hook）方法用
protected+ 空实现，子类按需覆盖，不强制 - 避免在模板方法中调用
this的非 final 实例方法——子类构造器未完成时可能触发未初始化行为
为什么不能用接口替代抽象类实现模板方法
Java 8+ 接口支持 default 方法，但没法声明 abstract 方法来强制子类实现具体步骤，更没法控制字段、构造器或继承链。模板方法依赖的是「继承时的初始化顺序」和「子类对父类受保护成员的可见性」，这两点接口做不到。
典型误用场景：用接口定义 execute() 和 doStep1()，再让多个类 implements ——此时 execute() 在每个实现类里都要复制一遍调用逻辑，根本没复用流程骨架。
- 接口无法持有状态（如中间计算结果、上下文对象），而模板方法常需跨步骤共享
protected字段 - 子类若同时实现多个接口，无法保证「流程入口」统一由某一方控制
- 编译期检查弱：接口不强制你实现所有步骤方法，容易漏掉关键环节
子类覆盖钩子方法时要注意执行时机和副作用
钩子（hook）不是必须实现的扩展点，比如 beforeExecute() 或 afterValidate()。但一旦子类覆盖了它，就要清楚它在整个模板流程中的确切位置——是在某个耗时操作前？还是异常抛出后？
容易踩的坑是：在 afterExecute() 钩子里做资源释放，却没考虑模板方法本身是否已因异常提前退出；或者在 isRetryAllowed() 这类布尔钩子里做了 I/O 操作，拖慢主流程。
- 钩子方法名建议带明确语义前缀：
should、before、after、on - 不要在钩子里 throw 新异常，除非模板方法已声明 throws 对应类型
- 如果钩子返回值影响后续流程（如是否跳过某步），确保默认实现有合理 fallback（如
return true;）
抽象类里的 protected 字段会影响子类的线程安全性
模板方法模式常通过 protected 字段传递上下文，比如 protected Map。这看似方便，但会带来隐式共享状态风险：多个线程并发调用同一实例的 templateMethod()，就会互相污染 context。
这不是模式本身的问题，而是实现时容易忽略的细节。尤其在 Spring 等框架中，若把模板类声明为 singleton bean，问题立刻暴露。
- 优先用方法参数传递数据，而非依赖实例字段
- 若必须用字段，确保每次调用前重置（如在
templateMethod()开头 new 一个新context） - 避免在
protected字段上做懒加载（if (xxx == null) xxx = init();），多线程下可能多次 init
实际写的时候，最麻烦的不是定义抽象类，而是判断哪些逻辑真该交给子类——有些看似可变的步骤，其实只是配置差异，用策略模式+参数化更干净。模板方法适合的是「流程固定、步骤语义固定、仅实现细节不同」的场景，比如 HTTP 请求生命周期、批处理作业阶段、ORM 实体状态流转。别为了套模式，硬把条件分支塞进钩子里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
