Go中用嵌入结构体+接口实现模板方法：嵌入具体baseWorkflow结构体（非接口），定义最小StepRunner接口约束DoStep/GetID，context和error全程透传包装，测试时用匿名结构体模拟实现。
Go 里怎么用嵌入+接口实现模板方法
模板方法模式在 Go 里不能靠继承，得靠组合和接口契约来模拟。核心是：把固定流程写死在结构体方法里，把可变步骤抽成接口方法，让具体工作流实现它。
常见错误是直接把所有逻辑塞进一个 Execute 函数，导致无法复用前置校验、日志、重试等公共逻辑；或者把接口定义得太宽，比如让每个工作流自己实现 Run + Rollback + Validate，结果不同工作流语义不一致，引擎调度时容易 panic。
- 定义统一入口：用一个非导出字段（如
baseWorkflow）封装通用执行链路，导出的Execute方法只调这个 - 接口只需最小契约：比如只强制实现
DoStep()和GetID()，其他像超时控制、上下文传递都由基类处理 - 避免空接口或泛型过度抽象：工作流类型差异大时，宁可用多个小接口（
Initializable、Transactional），也不要用一个Workflow接口塞满可选方法
为什么不用 embed interface 而要显式组合
有人想用 type MyWorkflow struct{ Workflow } 直接嵌入接口，结果发现编译不过——Go 不允许嵌入接口类型。这是语法限制，不是设计选择。
更关键的是，即使能嵌入，也会丢失类型信息：引擎做路由或指标打点时，需要知道具体是 *ApprovalWorkflow 还是 *DataSyncWorkflow，而接口嵌入后只剩 Workflow，反射也拿不到原始类型名。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法是嵌入具体结构体：比如
type ApprovalWorkflow struct{ baseWorkflow }，其中baseWorkflow是普通 struct，含logger、tracer等共享字段 - 接口只用于行为约束：声明
func (w *ApprovalWorkflow) DoStep(ctx context.Context) error，并让它实现StepRunner接口 - 别为了“看起来像继承”强行用泛型约束类型参数：比如
func Run[T StepRunner](t T)，这会让错误栈变深、调试困难，且无法在运行时做类型判断
context 和 error 如何在模板链路中透传
工作流常涉及多阶段异步操作，context.Context 必须从入口一路传到底层 DoStep，否则超时或取消信号会丢失；错误也要分层包装，不能裸 return errors.New("xxx")，否则上层无法区分是业务失败还是系统异常。
典型坑是：在 baseWorkflow.Execute 里生成了带 timeout 的 ctx，但调用 w.DoStep(ctx) 前忘了用 withValue 注入 traceID 或 workflowID，导致日志串不起来。
- 所有步骤函数签名必须是
DoStep(ctx context.Context) error，不允许省略 ctx 参数 - 错误要 wrap：用
fmt.Errorf("step validate failed: %w", err)，而不是fmt.Errorf("step validate failed: %v", err) - 公共 ctx 应该在
Execute开头就派生好，包含 traceID、workflowID、deadline，然后原样传给每一步，不要在中间步骤里重新context.WithTimeout
测试模板基类时如何隔离具体实现
测 baseWorkflow.Execute 逻辑（比如重试三次、记录耗时、统一 recover panic）时，如果每次都 new 一个真实工作流，就会耦合到具体业务逻辑，单元测试慢且不稳定。
最简单的办法是写一个匿名结构体实现接口，在测试里直接构造，而不是依赖真实类型。
func TestBaseWorkflow_Execute_RetryOnFailure(t *testing.T) {
var callCount int
wf := &mockStepRunner{
doStepFunc: func(ctx context.Context) error {
callCount++
if callCount < 3 {
return errors.New("temporary failure")
}
return nil
},
}
// ...
}
- mock 结构体字段用函数类型（如
doStepFunc func(context.Context) error），比用 testify/mock 更轻量、无反射开销 - 不要在 mock 里调真实数据库或 HTTP 客户端，哪怕加了
if testing.Testing()判断——测试环境变量不可靠，CI 可能漏掉 - 基类测试重点验证流程控制：比如第一次失败后是否 sleep、是否调了 logger.Warn、error 是否被正确 wrap 成
WorkflowError
真正难的不是写出模板结构，而是让每个新接入的工作流都老老实实遵守那几个接口约定。一旦有人绕过 Execute 直接调 DoStep，整个流程控制就失效了——这种事在代码审查里最容易被忽略。
