模板方法在Go中应通过接口定义钩子行为、结构体封装固定流程并组合实现；避免嵌入模拟继承，拆分可选接口或使用函数字段解决空方法问题；需重视错误传播、panic恢复与幂等清理；适用于流程稳定、步骤固定的场景。
模板方法的核心在于抽象流程，不是抽象类而是接口 + 组合
Go 没有继承和抽象类，所以不能照搬 Java 的 abstract class 写法。关键点是：用接口定义“钩子”行为，用结构体封装不变流程，再通过字段注入具体实现。常见错误是试图用嵌入（embedding）模拟继承，结果导致耦合变高、测试困难。
- 定义一个接口，比如
Processor，包含Setup()、Execute()、Teardown()等方法 - 写一个通用执行器结构体，如
WorkflowRunner，它持有一个Processor接口字段 -
Run()方法在内部按序调用p.Setup()→p.Execute()→p.Teardown()，流程完全固定
如何避免空方法实现污染接口
Java 里常把 beforeExecute() 设为默认空实现，但 Go 接口不允许默认方法。硬让所有实现都写空函数，既啰嗦又易漏。更合理的方式是拆分接口或用函数字段。
- 把可选行为抽成独立接口，例如
Preparer和Cleaner，主流程中用类型断言判断是否支持：if p, ok := runner.processor.(Preparer); ok { p.Prepare() } - 或者直接在结构体里加函数字段：
BeforeRun func() error，调用前判空即可 - 不要为了“统一”而强求所有实现都实现全部方法——Go 的接口是隐式实现的，越小越好
实际项目中容易忽略的生命周期与错误传播
模板方法最常出问题的地方不在结构，而在错误处理和资源释放时机。比如 Teardown() 被跳过，或 Execute() panic 导致后续清理不执行。
- 在
Run()中用defer+recover()捕获 panic，确保Teardown()总被执行 - 错误应逐阶段返回，不要只在最后汇总；建议统一返回
error，并在每个步骤后检查：if err := p.Setup(); err != nil { return err } - 若涉及资源（如文件句柄、DB 连接），
Teardown()必须是幂等的——重复调用不能 panic 或报错
什么时候不该用模板方法
当流程分支多、条件逻辑复杂，或不同子类间重叠极少时，强行套模板反而增加理解成本。Go 更倾向用函数选项（functional options）或简单函数组合。
立即学习“go语言免费学习笔记（深入）”；
- 如果只有两三个步骤，且每步逻辑差异大，直接写个
DoXxx(...)函数更清晰 - 如果需要动态切换流程顺序（比如 A→B→C 和 A→C→B 并存），模板方法的“固定骨架”就成了负担
- 并发场景下，
Execute()若需并行执行多个子任务，模板方法的串行假设就不成立
真正该用它的场景很明确：流程稳定、步骤固定、差异仅在具体操作细节——比如日志采集、ETL 任务、HTTP 中间件链初始化。
