go中封住模板方法绕过路径的关键是：将钩子函数设为非导出，仅暴露导出的run()方法统一调度，确保validate→setup→process→cleanup顺序执行且不可跳过。
Go 里没有 abstract class，怎么让 TemplateMethod 不被子类绕过？
Go 没有继承意义上的抽象类，靠组合实现模板方法时，最常踩的坑是：子类（即嵌入结构体）直接调用钩子函数，跳过主流程控制。比如本该走 Execute() 统一调度，结果用户手动调了 Before() 和 After()，顺序乱了、前置校验丢了。
关键不是“怎么写”，而是“怎么封住绕过的路”：
- 把钩子函数（如
Setup()、Process()）设为非导出（小写开头），只在模板结构体内部调用 - 对外只暴露一个导出的
Run()方法，它内部按序调用所有步骤，且不返回中间状态 - 如果必须允许外部定制行为，用函数字段（
func() error）替代方法重写，避免类型断言和反射
示例中常见错误写法：myTask.Process() 直接调；正确姿势只有 myTask.Run() —— 后者才保证 Validate() → Setup() → Process() → Cleanup() 链路完整。
组合嵌入时，struct 字段名影响方法查找顺序吗？
影响，而且容易误判。Go 的方法集基于类型，不是基于嵌入字段名。但如果你嵌入两个含同名方法的结构体（比如都带 Init()），编译器会报错：ambiguous selector。
立即学习“go语言免费学习笔记（深入）”；
实际编码中更隐蔽的问题是：嵌入结构体的方法被覆盖却不自知。
- 外层结构体定义了同名方法（哪怕签名不同），就会完全隐藏嵌入结构体的版本
- 嵌入的是指针类型（
*BaseRunner）还是值类型（BaseRunner），会影响方法集是否包含指针接收者方法 - 别依赖字段名来“区分”行为——Go 不支持重载，
task.Base.Init()这种写法非法，只能通过显式类型转换或包装函数间接调用
所以，模板结构体里别随便加同名方法；真要复用逻辑，用私有字段 + 显式委托，别赌方法查找顺序。
这本书给出了一份关于python这门优美语言的精要的参考。作者通过一个完整而清晰的入门指引将你带入python的乐园，随后在语法、类型和对象、运算符与表达式、控制流函数与函数编程、类及面向对象编程、模块和包、输入输出、执行环境等多方面给出了详尽的讲解。如果你想加入 python的世界，David M beazley的这本书可不要错过哦。 (封面是最新英文版的,中文版貌似只译到第二版)
template method 在 HTTP handler 或 CLI command 中怎么避免重复初始化？
典型场景：每个请求或每条命令都要跑一遍 LoadConfig()、ConnectDB()，但模板方法里又不能把它们写死在 Run() 开头——因为有些子类需要跳过或替换。
解决思路不是“抽成接口”，而是控制生命周期粒度：
- 把可复用的初始化逻辑拆成独立函数（如
newDBClient()），由模板结构体按需调用，而非强制所有子类继承 - 用
sync.Once包裹昂贵操作，但注意：它属于实例级，不是类型级；多个 task 实例仍会各自执行一次 - 若需全局单例（如共享 DB 连接池），初始化放在
init()函数或包变量中，模板方法里只做检查和赋值
错误示范：BaseCommand 构造函数里直接 sql.Open —— 导致每次 new 都连库；正确做法是延迟到 Run() 中首次用到时才初始化，并缓存到结构体字段。
为什么不用 interface + 函数参数模拟模板方法，而坚持用 struct 嵌入？
因为 interface 只能约束“有哪些方法”，管不住“调用顺序”和“执行上下文”。模板方法的核心价值不在“能扩展”，而在“强制流程不可跳过”。
比如 type Runner interface { Setup(), Process(), Cleanup() } 看似简洁，但调用方可以随意排列、漏掉某步、甚至并发调用——这已经不是模板方法，只是普通策略模式。
- struct 嵌入提供隐式契约：你嵌入了
BaseFlow，就默认接受它的Run()控制流 - 字段级封装让钩子函数天然不可见，比 interface 更强的约束力
- 性能上无差异，但调试时堆栈更清晰：你能看到
(*BaseFlow).Run→(*MyTask).Process，而不是一堆匿名函数跳转
真正难的是设计好钩子粒度——Process() 是该拆成 Fetch() + Transform()，还是保持原子？这取决于业务变更频率，而不是语法能不能支持。
