Go中模板方法模式通过接口+结构体嵌入+显式调用实现：定义含钩子方法的接口，骨架函数/方法接收该接口并显式调用钩子，具体类型实现接口后传入骨架执行。
Go 里没有抽象类，怎么写模板方法？
Go 没有继承、没有 abstract 关键字，所谓“模板方法模式”必须靠接口 + 嵌入结构体 + 显式调用约定来模拟。核心不是“强制子类实现”，而是定义一个公共骨架函数，把可变部分抽成接口方法，由使用者传入具体实现。
常见错误是试图用嵌入“自动覆盖”方法——struct A 嵌入 struct B 后，调用 A.Do() 如果 A 自己没定义 Do，才会走到 B.Do()；但如果你在 A 里又定义了 Do，它就完全屏蔽了 B.Do()，不会自动“委托”给子逻辑。
- 模板骨架必须是普通函数或结构体方法，且显式调用
self.HookXxx()这类钩子方法 - 钩子方法必须声明在接口中，结构体通过实现该接口来提供定制行为
- 嵌入的只是复用“骨架”，不是复用“逻辑分支”——分支逻辑永远来自接口实现，不是嵌入体本身
用嵌入结构体复用模板骨架的正确姿势
嵌入结构体只负责提供 Execute() 这类不变流程，所有可变步骤都定义为接口方法，并在骨架里以 t.Before()、t.Process() 形式调用。嵌入者（如 CSVExporter）只需实现接口，再把自身指针传给骨架即可。
典型错误：嵌入后直接调用 e.Execute() 却忘了 e 本身没实现 Exporter 接口，导致编译报错 cannot use e (type *CSVExporter) as type Exporter。
立即学习“go语言免费学习笔记（深入）”；
- 骨架结构体（如
BaseExporter）不实现接口，只依赖接口参数 - 具体类型（如
CSVExporter）必须实现完整接口，包括所有钩子方法 - 执行时要显式传参：
e.Execute(&csv)或用包装方法：csv.Run()内部调用BaseExporter.Execute(csv) - 嵌入位置无关紧要——嵌入
BaseExporter只是为了复用字段或辅助方法，不是为了“继承行为”
为什么不能靠匿名字段自动触发钩子？
因为 Go 的方法集规则很严格：如果 T 嵌入 S，那么 *T 的方法集包含 S 的所有指针方法，但前提是这些方法在 S 上定义时接收者是 *S；更重要的是，T 自己的方法会完全遮蔽 S 同名方法，且不会自动转发。
比如你写 func (e *CSVExporter) Process() { ... }，那 e.Process() 就永远走这个，哪怕 BaseExporter 里也有 Process()，也不会被调用——Go 不支持动态分发，也没有 super 调用语法。
- 钩子方法必须由骨架主动调用，且调用目标是接口变量，不是嵌入字段
-
BaseExporter里不能有Process()方法体，否则容易误以为它是默认实现；它只该有Execute(e Exporter)这种接受接口的入口 - 如果真需要默认行为，应放在接口方法的“默认实现函数”里，由具体类型选择是否内联调用，而非靠嵌入触发
实际写法：三步落地一个可用模板
不用抽象基类，也能让多个导出器共享初始化 → 校验 → 写入 → 清理流程，同时各自控制写入格式和字段映射。
- 定义接口：
type Exporter interface { Setup() error; Validate() error; WriteRow(row []string) error; Cleanup() error } - 写骨架函数：
func RunExporter(e Exporter) error { if err := e.Setup(); err != nil { return err }; ... return e.Cleanup() } - 具体类型实现接口并调用骨架：
func (c *CSVExporter) Export() error { return RunExporter(c) }—— 这里c是*CSVExporter，它实现了Exporter，所以能传进去
最容易被忽略的一点：接口方法的错误处理策略要统一。比如 Validate() 返回 error 表示中断流程，但有人会返回 nil 却默默跳过校验——这会让模板骨架失去控制力，变成“看起来用了模板，实则各写各的”。
