模板方法模式通过抽象类定义算法骨架，用final封装模板方法、abstract定义核心步骤、protected hook提供可选扩展；需避免构造器调用可重写方法及模板内误调子类方法。
模板方法模式的核心是定义算法骨架
它不解决“做什么”，而是规定“怎么做”的流程顺序，把可变行为延迟到子类实现。关键在于父类用 final 封装执行逻辑，用 abstract 或 hook 方法留出扩展点。
典型结构：抽象类 + 模板方法 + 钩子方法
常见错误是把所有步骤都设为抽象，导致子类被迫重写全部逻辑；或漏加 final，让子类意外覆写主流程。正确做法是：
- 模板方法（如
execute()）必须声明为final - 核心步骤（如
prepare()、process()）设为abstract，强制子类实现 - 可选步骤（如
onSuccess()、onFailure()）设为默认空实现的protected方法，即钩子（hook） - 避免在模板方法中调用子类可重写的方法（除明确设计的 hook 外），否则可能引发初始化问题
public abstract class DataProcessor {
// 模板方法：不可被重写
public final void execute() {
validate();
prepare();
process();
if (isSuccessful()) {
onSuccess();
} else {
onFailure();
}
cleanup();
}
protected abstract void prepare();
protected abstract void process();
protected abstract boolean isSuccessful();
private void validate() { /* 公共校验逻辑 */ }
private void cleanup() { /* 公共清理逻辑 */ }
// 钩子方法：子类可选择性覆盖
protected void onSuccess() {}
protected void onFailure() {}}
真实场景：支付流程的复用与定制
比如微信支付和支付宝支付共享「校验→生成订单→调用网关→结果解析→记录日志」主干，但每步具体实现不同。此时：
-
DataProcessor变成PaymentTemplate -
prepare()在子类中组装支付参数（微信用appId，支付宝用app_id） -
process()分别调用WXPayApi.invoke()或AlipayClient.execute() -
onSuccess()可在微信子类里触发模板消息，在支付宝子类里同步库存 - 若某天要加统一风控拦截，只需在
execute()中插入checkRisk()，所有子类自动生效
容易被忽略的细节：构造函数中不能调用可重写方法
如果在抽象类构造器里调用了 prepare() 这样的抽象方法，而子类字段尚未初始化，就会出现 NullPoi 或未定义行为。Java 初始化顺序决定了这点非常危险。
更隐蔽的问题是：模板方法内部若依赖子类的 static 字段或初始化块，也可能因类加载时机错乱导致值为 null。稳妥做法是只在 execute() 被显式调用后才进入子类逻辑。
