模板方法必须声明为final以锁定算法骨架，步骤方法用abstract或protected实现，钩子方法替代条件判断，禁止子类调用模板方法以防递归，泛型应避免约束模板主流程。
抽象类必须定义模板方法且设为 final
模板方法模式的核心是把算法骨架固定在父类，子类只能改步骤实现、不能破坏流程顺序。所以 templateMethod() 一定要声明为 final，否则子类可能覆写它，整个骨架就失效了。
常见错误是只把步骤方法设为 abstract 或 protected，却忘了锁住主流程。Java 和 C# 都要求显式加 final（C# 是 sealed），Python 虽无语法强制，但应在文档和命名（如 _execute()）上明确约束。
- 骨架流程中不该被重写的入口方法，一律加
final - 步骤方法用
abstract（强制子类实现）或protected+ 默认空实现（可选覆盖） - 避免在模板方法里调用
this的非 final 方法——可能触发子类过早初始化
钩子方法（hook method）比条件判断更易扩展
当算法某步需要“有则执行、无则跳过”，别在模板方法里写 if (shouldDoX()) 判断逻辑。应该提取成受保护的钩子方法，比如 shouldValidateInput()，默认返回 false，子类按需覆写。
这样既保持父类纯净，又避免把分支逻辑散落在模板中。一旦后续新增校验类型，只需新增子类并覆写钩子，不用动父类代码。
- 钩子方法命名建议以
should、is、after、before开头，语义清晰 - 不要在钩子里做重操作（如 IO、网络），它本意是轻量决策
- 多个钩子之间注意执行时序依赖，比如
beforeProcess()必须早于process()
子类覆写步骤时，禁止调用父类同名模板方法形成递归
这是非常隐蔽的坑：子类在实现 doStepA() 时，误调了 super.templateMethod()，而该方法内部又调了 doStepA() ——直接栈溢出。JVM 报错类似 java.lang.StackOverflowError，但堆栈里全是 doStepA 和 templateMethod 循环。
根本原因是混淆了“算法骨架”和“具体步骤”的职责边界。模板方法是顶层协调者，步骤方法只是执行单元，二者不可互相调用。
- 子类中所有
super.xxx()调用，只允许针对父类提供的钩子或工具方法，绝不能指向任何模板方法 - IDE 里给模板方法加
@Deprecated注解并写明 “DO NOT CALL FROM SUBCLASSES” 是实用提醒手段 - 单元测试应覆盖子类构造后直接调用模板方法的场景，验证无意外递归
泛型抽象基类要谨慎暴露类型参数给模板方法
如果抽象类定义为 AbstractProcessor<t></t>，而模板方法签名是 final void execute(T input)，看似灵活，实则限制子类自由：所有子类必须处理同一类型 T，无法支持不同输入结构。
更合理的方式是让模板方法不绑定具体类型，靠步骤方法各自适配。例如父类定义 execute() 无参，子类在 parseInput() 里做类型转换，返回内部统一的上下文对象。
- 泛型参数适合约束工具方法（如
validate(T item)），而非模板主流程 - 若真需多类型支持，用组合优于继承：把共用逻辑抽成工具类，由不同算法类持有引用
- Java 中
? extends T等通配符会让子类覆写变得更复杂，多数情况下纯属过度设计
真正难的不是写出能跑的模板，而是预判哪些步骤未来一定变化、哪些必须死死锁住。每次加新子类前，先问一句：这个改动，是应该新增一个子类，还是该调整钩子逻辑？答错一次，骨架就开始松动。
