Go中可用组合+函数字段或接口实现模板方法模式：算法骨架在结构体方法中固定执行顺序，可变步骤通过func字段或接口方法注入，确保流程控制权明确且细节可定制。
Go 中没有继承，模板方法模式要怎么写
Go 语言不支持类继承，所以传统面向对象中靠抽象基类 + 子类重写钩子函数的模板方法模式无法直接套用。但你可以用组合 + 函数字段 + 接口来等效实现：把算法骨架定义在结构体里，把可变步骤抽成 func() 类型字段或接口方法。
关键不是“模拟继承”，而是“控制流程权”——谁决定执行顺序，谁负责填充细节。
- 算法主干（如
Execute()）放在一个结构体方法里，内部按固定顺序调用若干可替换的步骤 - 这些步骤要么是结构体的字段（
func() error），要么是某个接口的方法（如Preprocess()、Validate()） - 使用者通过赋值字段或传入实现了接口的实例来定制行为
用函数字段实现轻量级模板逻辑
适合步骤少、逻辑简单、不想定义额外接口的场景。把变化点声明为结构体字段，运行时动态注入。
type Processor struct {
Preprocess func() error
DoWork func() error
Cleanup func() error
}
func (p *Processor) Execute() error {
if p.Preprocess != nil {
if err := p.Preprocess(); err != nil {
return err
}
}
if p.DoWork == nil {
return fmt.Errorf("DoWork not set")
}
if err := p.DoWork(); err != nil {
return err
}
if p.Cleanup != nil {
p.Cleanup()
}
return nil
}
使用时直接赋值匿名函数或已有函数：
立即学习“go语言免费学习笔记（深入）”；
p := &Processor{
Preprocess: func() error { log.Println("setup"); return nil },
DoWork: doActualJob,
Cleanup: func() { log.Println("teardown") },
}
p.Execute()
注意：nil 检查必须做，否则 panic；字段命名建议带动词前缀（如 OnBefore、OnAfter），避免和普通数据字段混淆。
用接口 + 组合替代继承式模板
当步骤较多、需要复用多个实现、或希望类型安全更强时，定义接口更清晰。模板结构体持有该接口实例，把可变逻辑委托出去。
type StepRunner interface {
Setup() error
Run() error
Teardown()
}
type TemplateRunner struct {
runner StepRunner
}
func (t *TemplateRunner) Execute() error {
if err := t.runner.Setup(); err != nil {
return err
}
if err := t.runner.Run(); err != nil {
return err
}
t.runner.Teardown()
return nil
}
这样你就能写出多个 StepRunner 实现，比如 *HTTPHandlerRunner 或 *FileProcessorRunner，它们各自封装领域逻辑，而 TemplateRunner.Execute() 始终保持不变。
优势是可测试性高（mock 接口即可）、职责分离明确；缺点是多一层间接调用，不过对绝大多数业务代码性能无感。
容易踩的坑：panic、生命周期、错误处理不一致
实际项目中最常出问题的不是结构设计，而是细节失控：
-
func字段未初始化就调用 → 一定加nil检查，或改用接口 + 构造函数强制传入 - 在
Cleanup阶段 panic 导致defer失效或资源泄漏 → 所有钩子函数都应 recover 异常，或约定不 panic - 不同步骤返回错误类型不统一（有的返回
fmt.Errorf，有的返回自定义错误）→ 建议统一用一个错误构造函数，比如ErrSetupFailed，方便上层分类处理 - 模板结构体本身含状态（如
ctx、logger），但钩子函数没传入 → 把共享状态提成字段，让所有钩子都能访问，别靠闭包捕获（易造成 goroutine 泄漏）
真正难的不是写出模板结构，而是让每个可插拔的步骤都遵守同一套契约：输入确定、副作用可控、错误语义清晰。
