模板方法模式的核心是“钩子”与“骨架分离”，而非继承；应将不变流程抽为具体方法，可变步骤设为空方法或带默认实现的钩子，避免过早使用抽象基类。
模板方法模式的核心不是继承，而是“钩子”和“骨架分离”
Python里用模板方法，关键不是写一堆 AbstractBaseClass，而是把不变的流程骨架抽成一个具体方法，把可变步骤留成空方法或带默认实现的钩子（hook）。很多人一上来就猛写 @abstractmethod，结果发现子类被迫重写太多、测试难、扩展僵硬——其实多数场景下，用普通方法 + pass 或 return None 就够了，语义更轻、调试更直接。
常见错误现象：TypeError: Can't instantiate abstract class，往往是因为过早引入抽象基类，而实际只需要运行时检查（比如在模板方法开头加 if not hasattr(self, 'step_x'):）。
- 骨架方法（如
run_pipeline()）应是public且final意图（虽Python无final关键字，但命名用_run_pipeline或文档注明） - 子步骤默认用
def step_validate(self) -> None:形式，不强制抽象；需要强制时再加raise NotImplementedError - 钩子方法（如
on_error(self, exc)）必须提供空实现，避免子类遗漏导致流程中断
用 __init__ 和属性控制算法变体，比多层继承更灵活
当不同子类只在少数参数或策略上差异（比如日志级别、重试次数、超时值），别急着建新类——直接让构造函数接收配置，存在实例属性里。模板方法内部通过 self.retry_times 这类属性做分支，比靠继承树区分更易组合、更易单元测试。
使用场景：同一数据处理流程，开发环境跳过缓存，生产环境启用熔断；或 A 客户要 XML 输出，B 客户要 JSON，但解析逻辑完全一致。
立即学习“Python免费学习笔记（深入）”；
- 避免在骨架方法里硬编码条件判断（如
if self.env == 'prod'），改用策略对象：self.cache_strategy.get(key) - 配置项尽量走
**kwargs或dataclass参数对象，别散落在多个__init__参数中 - 如果某步骤完全跳过，钩子方法里直接
return，不要抛异常或返回特殊值干扰主流程
super().step_prepare() 不是必须的，但调用时机决定扩展安全边界
当父类钩子已有基础逻辑（比如自动记录开始时间），子类想增强而非替换，才需要显式调用 super()。但要注意：这个调用必须放在子类逻辑之前还是之后？这直接影响状态一致性。例如 step_connect() 中，父类负责打日志，子类负责建立连接——日志应在连接前打，否则失败时日志里没有上下文。
容易踩的坑：super().step_cleanup() 放在子类清理代码之后，导致子类释放的资源被父类二次释放（如文件句柄已关，父类又调 .close() 报 ValueError: I/O operation on closed file）。
- 推荐约定：父类钩子做“前置准备”和“后置兜底”，子类钩子做“核心动作”；所有
super()调用统一放在子类方法开头（前置）或结尾（后置） - 若不确定顺序，用
try/finally包裹子类逻辑，在finally里调用父类清理，确保执行 - 对异步方法（
async def step_fetch），await super().step_fetch()必须显式await，漏掉会返回 coroutine 对象而非结果
测试模板方法时，重点不是测子类，而是验证骨架的“不越界”
真正难测的是骨架本身是否意外调用了未定义的钩子、是否在异常路径下跳过了必要清理、是否把子类返回值误当布尔值判断。所以单元测试应聚焦父类实例，用 unittest.mock 打桩钩子，观察调用顺序和参数，而不是跑通整个子类流程。
示例：测试 run_pipeline() 是否严格按 step_init → step_process → step_cleanup 顺序执行：
from unittest.mock import Mock p = ProcessorBase() p.step_init = Mock() p.step_process = Mock() p.step_cleanup = Mock() p.run_pipeline() assert p.step_init.called_before(p.step_process) assert p.step_process.called_before(p.step_cleanup)
- 避免对每个子类都写一遍完整流程测试；用一个测试覆盖骨架，另用小单元测试覆盖各钩子逻辑
- 检查异常传播：在
step_process抛异常时，step_cleanup是否仍被执行（可用side_effect模拟） - 性能影响：骨架方法里少用
hasattr()或getattr()动态检查，高频调用场景下，改用实例属性标记（如self._has_custom_validation = True）
最常被忽略的一点：模板方法不是为“未来可能扩展”而设计，而是为“当前已有多个相似流程，且差异点明确、稳定”。如果钩子方法超过4个，或者子类开始互相 copy/paste 钩子实现，说明骨架抽象粒度错了——该拆成策略模式或用函数式组合。
