go中用函数字段实现模板方法：定义含validate/dowork/notify等函数字段的结构体，execute方法按序调用，调用方初始化时赋值具体函数并做非空检查。
Go 里没有继承，怎么写模板方法？
Go 不支持类继承，所以没法像 Java 那样靠抽象基类 + 子类重写钩子函数来实现传统模板方法。但骨架复用的需求真实存在——比如“执行前校验 → 执行核心逻辑 → 发送通知 → 记录日志”这种流程固定、仅中间步骤可变的场景。
实际做法是用 interface{} 定义协议，把可变部分抽成函数字段或回调参数，让调用方注入具体行为。不是“子类覆盖”，而是“结构体组合 + 函数赋值”。
- 定义一个结构体，内嵌公共流程逻辑（如
Execute()），并预留validate()、doWork()、notify()等字段，类型为函数签名 - 调用方创建实例时，直接给这些字段赋值具体函数，比如
tmpl.validate = myValidateFunc - 避免用空接口或反射，保持类型安全和 IDE 可跳转性
用 struct 字段存函数比传参更灵活？
两种常见写法：一种是每次调用 Execute() 时把钩子函数当参数传入；另一种是把钩子函数作为结构体字段预先设好。后者更适合需要复用同一套策略多次执行的场景，比如定时任务中不同业务共用同一执行器。
字段方式能自然携带上下文（比如 DB *sql.DB 或 logger *zap.Logger），而纯参数方式容易导致每次调用都得重复传一堆依赖。
立即学习“go语言免费学习笔记（深入）”；
- 字段方式示例：
type Processor struct { validate func() error doWork func() error notify func(error) } func (p *Processor) Execute() error { if err := p.validate(); err != nil { return err } err := p.doWork() p.notify(err) return err } - 字段必须是导出的（首字母大写）才能被外部赋值；若想限制修改，可提供构造函数封装初始化逻辑
- 注意函数字段未初始化时是
nil，直接调用会 panic，务必在Execute()开头做非空检查
为什么不用 embed + interface 实现“伪继承”？
有人尝试用 embed 嵌入一个含默认方法的结构体，再让业务结构体实现某个 interface 来覆盖行为。这看似接近模板方法，但实际问题不少。
Go 的嵌入只是字段展开 + 方法提升，并不改变方法绑定目标——你调用的是嵌入字段的方法，不是当前结构体的方法。除非显式重写（即定义同名方法并内部调用业务逻辑），否则无法真正“替换”行为。
- 如果只靠
embed，validate()永远调用的是默认实现，业务结构体上定义的Validate()方法不会自动被调用 - 要让它生效，还得在嵌入结构体的方法里手动查当前对象是否实现了某接口，再做类型断言调用——这已经脱离模板方法本意，变成运行时策略分发了
- 不如直接用函数字段干净：意图明确、无反射开销、单元测试易 mock
容易踩的坑：闭包捕获变量引发状态污染
当多个 Processor 实例共享同一个外部变量（比如循环中的索引 i），又在函数字段里直接引用它，就可能所有实例最终都看到最后一个值——这是 Go 里典型的闭包陷阱。
尤其在批量初始化处理器时（比如遍历 map 构建一组 Processor），这个问题高频出现。
- 错误写法：
for k, v := range configs { p := &Processor{} p.doWork = func() error { return runTask(k, v) } // k,v 是循环变量，会被所有闭包共享 } - 正确写法：在循环体内用局部变量复制值，或把参数显式传入匿名函数：
for k, v := range configs { k, v := k, v // 显式复制 p := &Processor{} p.doWork = func() error { return runTask(k, v) } } - 更推荐的方式是把配置项作为结构体字段存下来，而不是靠闭包捕获——更清晰，也更容易测试
真正难的不是语法实现，而是判断哪些步骤该固化、哪些该开放——比如“重试逻辑”看起来可变，但其实多数业务都需要指数退避+最大次数限制，这时候它就该进骨架，而不是暴露成钩子。
