Go中可用接口+组合+函数字段实现模板方法模式，固定流程骨架并允许子类定制步骤细节，如PaymentProcessor通过字段注入可变逻辑。
模板方法模式在 Go 中没有抽象类怎么办
Go 语言不支持抽象类和继承，所以不能像 Java 那样用 abstract class + final method 强制子类实现钩子。但模板方法的核心诉求是：**固定流程骨架，允许子类定制步骤细节**——这完全可以用 Go 的接口 + 组合 + 函数字段来实现，而且更轻量、更清晰。
关键思路是把“模板方法”定义为一个结构体的公开方法，把可变步骤声明为该结构体的字段（类型为函数），初始化时由调用方注入具体逻辑。
- 避免定义一堆空接口或泛型约束，先从具体业务场景出发设计字段
- 不要试图模拟“父类调用子类方法”，而是让调用方显式传入
func()或func() error - 如果步骤有固定顺序和条件分支，把这些控制逻辑写死在模板方法里，只把“做什么”开放出去
用 struct 字段模拟 hook 方法：一个支付流程示例
假设你要统一管理「下单 → 扣库存 → 调支付网关 → 更新订单状态」的流程，但不同渠道（微信/支付宝/余额）的「调支付网关」和「更新订单状态」逻辑不同。这时可以把后两步设为可替换的函数字段。
type PaymentProcessor struct {
DeductStock func(orderID string) error
CallGateway func(orderID string, amount float64) (string, error)
UpdateStatus func(orderID string, txID string, success bool) error
}
func (p *PaymentProcessor) Execute(orderID string, amount float64) error {
if err := p.DeductStock(orderID); err != nil {
return err
}
txID, err := p.CallGateway(orderID, amount)
if err != nil {
return err
}
return p.UpdateStatus(orderID, txID, err == nil)
}
使用时只需填充字段：
立即学习“go语言免费学习笔记（深入）”；
wechatProc := &PaymentProcessor{
DeductStock: func(orderID string) error {
return deductStockFromRedis(orderID)
},
CallGateway: func(orderID string, amount float64) (string, error) {
return callWechatPayAPI(orderID, amount)
},
UpdateStatus: func(orderID string, txID string, success bool) error {
return updateOrderInDB(orderID, "wechat", txID, success)
},
}
什么时候该用 interface 而不是函数字段
当某一步骤本身包含多个关联行为（比如「日志记录 + 重试 + 熔断」），或者需要复用状态（如 HTTP client、DB connection），那就该提取成接口。函数字段适合简单、无状态、单点替换；接口适合有内聚职责的组件。
- 例如「通知用户」步骤：如果是发短信/邮件/站内信，且每种都需配置通道、模板、发送器，就定义
Notifier接口，而不是三个独立的func字段 - 注意接口方法名不要带 “Do” “Execute” 这类泛称，用业务语义命名，如
SendReceiptEmail()、PushPaymentResult() - 接口实现应尽量无副作用，把错误处理和重试策略留给模板方法统一控制（否则流程不可控）
容易踩的坑：panic、context 和错误传播
模板方法本质是流程编排，一旦某个 hook panic，整个流程中断；若 hook 忘记检查 ctx.Done()，可能阻塞超时；若错误没被正确返回，上层无法感知失败。
- 所有 hook 函数签名建议统一为
func(ctx context.Context, ...) error，模板方法传入同一份ctx - 不要在 hook 里直接
log.Fatal或os.Exit，这会绕过模板方法的错误恢复逻辑 - 如果某步必须重试（如调第三方 API），别把它塞进 hook —— 应该由模板方法内部封装重试逻辑，hook 只负责“执行一次”
- 慎用闭包捕获外部变量传给 hook，容易引发 goroutine 泄漏或状态错乱（尤其是循环中创建 processor）
最常被忽略的是：模板方法本身要不要支持取消？如果流程中某步耗时不可控（比如长轮询），就必须在每个 hook 入口加 select { case ，否则 ctx.WithTimeout 形同虚设。
