如何使用Golang实现模板方法模式流程控制_Golang模板方法业务逻辑示例

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 形同虚设。