模板方法在Go中通过函数参数或接口注入可变步骤，核心是固定流程骨架与分离变化点；函数参数适合简单场景，接口+结构体嵌入适用于多步骤、需共享状态的场景，且必须显式实现接口方法。
模板方法的核心是定义固定流程骨架
Go 没有继承和抽象类，所以不能像 Java 那样靠 abstract func() 强制子类实现。但模板方法的本质不是语法机制，而是「把不变的流程提出来，把可变的步骤留给调用方决定」。关键在于：用函数参数或接口把步骤“注入”到主流程中。
用函数类型参数实现最轻量的模板方法
适合步骤少、逻辑简单、不需复用步骤实现的场景。比如日志上报前的预处理流程：校验 → 序列化 → 发送 → 清理，其中只有序列化和发送可能变化。
-
Process函数接收serialize和send两个func([]byte) error类型参数，流程顺序完全固定 - 调用方传入具体实现，比如用
json.Marshal还是protobuf.Marshal，不影响主干逻辑 - 避免在流程里做条件判断选分支——那会破坏“固定骨架”，应让调用方自己组合函数
func Process(data interface{}, serialize func(interface{}) ([]byte, error), send func([]byte) error) error {
if data == nil {
return errors.New("data is nil")
}
b, err := serialize(data)
if err != nil {
return err
}
return send(b)
}
用接口 + 结构体嵌入模拟“抽象基类”行为
当步骤多、需要共享状态（如配置、缓存、上下文）、或步骤间有依赖时，接口更清晰。重点不是“继承”，而是让调用方实现接口，再把实例传给模板函数。
- 定义
Processor接口，含Validate、Transform、Persist等方法 - 模板函数
Run按序调用这些方法，不关心具体实现 - 结构体实现该接口时，可内嵌通用字段（如
*sql.DB或context.Context），避免每个方法重复传参 - 别在接口里塞太多方法——步骤膨胀后难维护，按业务边界拆成多个小接口更灵活
type Processor interface {
Validate() error
Transform() error
Persist() error
}
func Run(p Processor) error {
if err := p.Validate(); err != nil {
return err
}
if err := p.Transform(); err != nil {
return err
}
return p.Persist()
}
为什么不用 embed + 匿名字段自动转发？
有人尝试用嵌入一个“默认实现”结构体，再覆盖部分方法，看似接近 OOP 的模板方法。但 Go 不支持方法重写语义，匿名字段只是字段提升，不会改变调用目标——p.Transform() 调用的仍是嵌入字段的方法，而非你新定义的同名方法，除非显式重定向。
立即学习“go语言免费学习笔记（深入）”；
- 若结构体
A嵌入DefaultProcessor，又定义了Transform()方法，A.Transform()是新的实现，但A本身仍满足Processor接口，因为它的方法集包含Transform - 真正危险的是：误以为嵌入后能“自动替换”步骤，结果运行的还是默认逻辑，调试时才发现没生效
- 接口实现必须显式提供全部方法，这是 Go 的确定性保障，别绕开它去模拟不确定的行为
Transform 依赖 Validate 设置的某个字段，但接口没声明这个契约。这种时候，文档比代码更重要。 
