Go中模板方法模式用组合替代继承，通过导出结构体字段（如函数或io.Reader/Writer接口）注入可变行为，非导出方法封装固定流程，钩子必须返回error而非依赖recover。
模板方法模式在 Go 里没有抽象类，怎么办
Go 没有继承和抽象类，所以不能照搬 Java/C++ 那套 abstract class + final method 的写法。核心思路得换：用组合代替继承，用函数字段（func()）或接口注入“可变步骤”，把不变流程封装在普通结构体方法里。
关键不是“定义抽象模板”，而是“把固定骨架和可插拔行为拆开”。常见错误是强行模拟继承，比如嵌入一个空接口字段再 runtime panic，这既难测又违背 Go 的显式哲学。
- 用结构体字段保存回调函数（如
beforeHook func()、process func() error） - 定义清晰的接口描述“变化的部分”，例如
Processor接口含Validate()和Execute() - 模板主方法（如
Run()）只调用字段或接口方法，不关心具体实现
如何让模板主流程不可被子类覆盖
Go 里没有 final 方法，但你可以通过封装+非导出字段+明确命名来达成等效效果。重点不是语法锁死，而是让使用者“没理由也没途径去重写主流程”。
典型做法是把主逻辑放在非导出方法（如 run()），而暴露的导出方法（如 Run()）只是简单调用它；同时把可定制字段设为导出（便于设置），但主干逻辑不暴露修改入口。
立即学习“go语言免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 主流程方法名用小写（如
execute()），仅在包内调用 - 对外只提供
Run()这样的导出方法，内部固定调用t.execute()+ 字段函数 - 避免把整个结构体字段全导出，只导出需要配置的行为字段（如
OnSuccess func()）
使用 io.Reader / io.Writer 作为钩子参数的场景
当模板方法涉及 I/O 流控制（如日志预处理、数据清洗管道），直接传 io.Reader 和 io.Writer 比传函数更符合 Go 习惯，也天然支持组合与测试。
例如构建一个通用文件处理器：主流程固定为 “读 → 校验 → 转换 → 写”，但读写目标可以是 bytes.Buffer（单元测试）、os.File（生产）、甚至 gzip.Writer（压缩输出）。这时钩子不是函数，而是接口值。
- 结构体字段定义为
Input io.Reader和Output io.Writer - 主方法中用
io.Copy()或json.NewDecoder(t.Input).Decode()等标准方式操作 - 测试时传
strings.NewReader("...")和new(bytes.Buffer)，无需 mock
type FileProcessor struct {
Input io.Reader
Output io.Writer
Verify func([]byte) error
}
func (fp *FileProcessor) Run() error {
data, err := io.ReadAll(fp.Input)
if err != nil {
return err
}
if fp.Verify != nil {
if err := fp.Verify(data); err != nil {
return err
}
}
_, err = fp.Output.Write(data)
return err
}
为什么不要在模板方法里做 panic/recover 控制流
有人试图用 defer + recover 在主流程里捕获钩子函数 panic，然后转成错误返回——这会掩盖真实调用栈，破坏错误溯源，也违背 Go “error is value” 的原则。
钩子函数本身就应该返回 error。如果它内部 panic，说明它没遵守契约，该修的是钩子，不是模板主流程去兜底。
- 所有钩子函数签名必须是
func() error或类似带 error 返回的形式 - 主流程统一检查每个钩子的 error 并短路返回，不引入 recover
- 测试时用
assert.Panics显式验证非法钩子行为，而不是让它在运行时爆炸
真正难处理的不是“钩子出错”，而是“钩子没按约定返回 error 却 panic 了”——那说明设计契约没对齐，得从接口定义和文档上解决，不是靠 recover 补漏。
