go中模板方法模式用组合+接口+函数字段实现，避免继承；骨架函数独立为包级函数，依赖最小接口，通过接口方法调用具体行为，不耦合实现细节。
Go 里没有继承，怎么写模板方法模式
直接说结论：用组合 + 接口 + 函数字段，比继承更清晰，也更符合 Go 的设计哲学。硬套类继承式模板方法（比如想定义 abstract method）会卡在编译器报错，因为 Go 没有 abstract 关键字，也没有子类 override 机制。
典型错误现象是试图写一个带未实现方法的 struct，然后让另一个 struct “继承”它——go build 直接失败，提示 undefined 或 cannot use … as … value。
- 把“算法骨架”抽成普通函数，接收一个接口类型参数（比如
Processor），该接口声明子类需提供的行为（如Setup()、Execute()、Teardown()） - 具体实现不嵌入父 struct，而是单独实现接口；骨架函数只调用接口方法，不关心谁实现
- 如果需要共享状态或预设逻辑，用字段注入（比如把
*log.Logger或配置结构体作为字段传入实现类），而不是靠“父类字段”隐式继承
templateMethod 函数怎么设计才不耦合
关键不是“怎么定义骨架”，而是“怎么让骨架不依赖具体实现”。常见错误是把 templateMethod 写死在某个 struct 里，又让它调用自己未导出的方法，结果外部无法替换行为。
正确做法是把骨架逻辑完全独立出来，作为包级函数，只依赖最小接口：
立即学习“go语言免费学习笔记（深入）”；
func RunPipeline(p Processor) error {
if err := p.Setup(); err != nil {
return err
}
if err := p.Execute(); err != nil {
return err
}
return p.Teardown()
}
这里 Processor 是接口，RunPipeline 不知道也不需要知道 p 是 *HTTPHandler 还是 *FileImporter。
- 避免在骨架函数里 new 具体类型（比如
&HTTPHandler{…}），那会让调用方失去控制权 - 如果骨架需要可选步骤（比如某些流程跳过
Teardown），用函数字段替代接口方法：接口加ShouldTeardown() bool，比强行实现空方法更明确 - 参数尽量用值或接口，别传指针到内部状态——否则不同实现可能意外共享数据
为什么不用 embed 匿名字段模拟继承容易翻车
有人试过在子 struct 里 embed 一个“基类” struct，再覆盖其方法。Go 不支持方法覆盖，嵌入只是委托调用，Base.Do() 调用的永远是 Base 自己的方法，不会自动转向子 struct 的同名方法。
典型错误代码：
type Base struct{}
func (b *Base) Template() { b.step1(); b.step2() }
func (b *Base) step1() { fmt.Println("base step1") }
func (b *Base) step2() { fmt.Println("base step2") }
type Child struct {
Base // ← 这里 embed 不会重定向 step2 调用
}
func (c *Child) step2() { fmt.Println("child step2") } // ← 这个方法永远不会被 Template() 调到
- 嵌入后
c.Template()输出仍是两行 “base”，因为Template方法体内调用的是b.step2()，不是c.step2() - 如果硬要靠嵌入+重命名绕开（比如
base Base+ 显式调用c.base.step1()），代码立刻变脆：每个子类都要手动重写所有骨架调用点 - 真正需要复用逻辑时，用私有 helper 函数（如
defaultSetup()）更安全，调用方按需组合，不靠语言特性“假装继承”
测试 templateMethod 时 mock 哪些东西最实际
测试重点不是“骨架函数有没有跑”，而是“它是否按顺序、按条件调用了预期的接口方法”。最容易忽略的是错误传播路径和边界条件。
比如 RunPipeline 在 Setup() 失败时不该调 Execute()，但很多人只测 happy path。
- mock 实现必须能控制每个方法的返回值（尤其是
error），用匿名结构体比完整 struct 更轻量：Processor = &mockProc{setupErr: io.EOF} - 别 mock 日志或 HTTP 客户端——那些是实现细节；要 mock 的是接口方法本身的行为契约
- 如果骨架里有 sleep 或 retry，测试时用
time.AfterFunc或注入clock Clock接口，避免真实等待
复杂点在于：当多个实现共用同一骨架，但各自对 Execute() 的幂等性、并发安全要求不同时，骨架函数本身无法替你保证——那得靠每个实现自己处理，别指望“父类”兜底。
