Go的模板方法应使用函数字段或接口组合实现，而非模拟Java抽象类；必填步骤需显式传入，避免隐式依赖，强调意图清晰、可替换、可验证。
模板方法的核心是定义骨架，不是写死逻辑
Go 没有继承和抽象类，所以不能照搬 Java 的 abstract class + final method 写法。强行用嵌入结构体+接口模拟，反而会让调用链变深、语义模糊。真正实用的 Go 风格模板方法，是用函数字段（func()）或接口组合来“注入”可变步骤。
用结构体字段存钩子函数，最轻量可控
把变化的部分声明为结构体的函数类型字段，在主流程中直接调用。这种方式零依赖、易测试、不隐藏控制流。
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
}
-
Validate和Charge是强制实现步骤，Notify是可选钩子 - 调用方完全掌控每个步骤的具体行为，无需导出子类或重写方法
- 测试时可直接传入 mock 函数，不用构造整套继承树
用接口组合替代“抽象基类”，更符合 Go 习惯
如果多个处理器共享部分逻辑（比如日志、重试），可以把公共行为抽成独立函数，再让具体类型实现差异接口。不要试图塞进一个“父接口”里。
type Payable interface {
Validate() error
Charge() error
}
type EmailNotifier interface {
SendReceipt(email string) error
}
func ProcessPayment(p Payable, n EmailNotifier, email string) error {
if err := p.Validate(); err != nil {
return err
}
if err := p.Charge(); err != nil {
return err
}
if n != nil {
_ = n.SendReceipt(email)
}
return nil
}
-
Payable和EmailNotifier是正交接口，谁需要谁实现 -
ProcessPayment是普通函数，不绑定任何类型，复用性高 - 没有“模板类”的概念，只有清晰的职责切分和显式依赖
别在 init 或 New 里自动注册钩子，会破坏可预测性
常见错误是写一个 NewPaymentProcessor()，内部偷偷给 Validate 字段赋值默认函数。这会让使用者误以为流程已完备，实际却掩盖了必填项。
- 所有必填钩子必须由调用方显式传入，或 panic 提示缺失
- 避免使用全局变量或单例注册表来“自动装配”，那会引入隐式依赖和并发风险
- 如果真要简化初始化，提供带参数的构造函数（如
NewWithStripe(...)），而不是无参New()
Go 的模板方法本质是控制反转（IoC）的一种轻量表达：你决定流程骨架，我负责填内容。关键不在“模式名字”，而在是否让每一步的意图清晰、可替换、可验证。一旦开始嵌套结构体、加标签、搞反射，就离 Go 的直觉越来越远。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
