Go中模板方法模式用函数字段或接口实现：函数字段轻量适合无状态流程，接口组合适合需共享状态的场景；必填步骤须显式校验非空，禁用嵌入模拟继承。
Go 里没有抽象类和继承，所以不能照搬 Java 的 abstract class + final method 写法；但模板方法模式的本质不是语法，而是「流程骨架固定、步骤实现可插拔」——这完全可以用函数字段或接口组合干净落地。
用结构体 + 函数字段实现最轻量模板
适合一次性流程、CLI 命令、HTTP 中间件钩子等场景。不引入接口，零类型定义，测试时直接传 mock 函数即可。
关键点：
-
Run()是唯一入口，流程顺序硬编码，不可覆盖 - 必填步骤（如
Validate、Process）在Run()中显式判空并返回错误，不默认 fallback - 可选步骤（如
Teardown）允许为nil，调用前必须判空，否则 panic - 闭包可捕获上下文变量，比接口更灵活，但无法复用步骤逻辑
type PaymentProcessor struct {
Validate func() error
Charge func() error
Notify func() error
}
func (p *PaymentProcessor) Execute() error {
if p.Validate == nil {
return fmt.Errorf("Validate not set")
}
if err := p.Validate(); err != nil {
return err
}
if p.Charge == nil {
return fmt.Errorf("Charge not set")
}
if err := p.Charge(); err != nil {
return err
}
if p.Notify != nil {
_ = p.Notify()
}
return nil
}
用接口 + 显式实现替代“抽象基类”
当多个流程共享状态（如 DB 连接、日志器、重试配置），或步骤间有依赖（如 Transform 需要 Validate 的输出），接口组合更清晰、易维护。
立即学习“go语言免费学习笔记（深入）”；
注意陷阱：
- 别把所有步骤塞进一个大接口（如
Processor含 8 个方法），按业务切分小接口（如Validator、Persister）更利于组合和 mock - 结构体实现接口时，可内嵌通用字段（如
*sql.DB），避免每个方法重复传参 - Go 不支持方法重写：若用匿名嵌入“默认实现”，
p.Transform()调用的仍是嵌入字段的方法，不会自动路由到你新写的同名方法
为什么别用 embed + 匿名字段模拟继承
常见误操作：定义一个 BaseProcessor 结构体，含默认 Setup() 和 Teardown()，再让 CoffeeProcessor 嵌入它并重写 Brew()。结果是：CoffeeProcessor.Brew() 永远调不到你重写的版本，因为 Go 的方法调用目标由值的静态类型决定，不是运行时动态绑定。
真实行为：
-
type CoffeeProcessor struct{ BaseProcessor }→CoffeeProcessor.Brew()调用的是BaseProcessor.Brew() - 要真正替换，必须显式重定向：
func (c *CoffeeProcessor) Brew() { ... }，且不能依赖嵌入字段自动转发 - 这种写法徒增嵌套层级，语义模糊，违背 Go 的“显式优于隐式”原则
接口组合 vs 函数字段：怎么选
判断依据就一条：是否需要跨步骤共享状态或复用逻辑。
- 纯流程控制（如日志上报三步：校验→序列化→发送），用函数参数最直接：
Process(data, json.Marshal, http.Post) - 需共享缓存、重试次数、context 或中间结果（如
Transform()输出要传给Persist()），必须用接口+结构体，靠字段承载状态 - 混合场景（如大部分步骤固定，仅一两个可插拔），可将可变步骤声明为接口字段，其余逻辑写死在
Run()里
最容易被忽略的一点：无论哪种方式，**必填步骤绝不能在 NewXXX() 构造函数里偷偷赋默认实现**——这会让使用者误以为流程已完备，实际掩盖了契约缺失，破坏可验证性。
