模板方法模式本质是“虚函数+final”实现的面向对象控制反转，非C++模板；基类用final封主流程、纯虚函数留钩子，子类仅override do_前缀虚函数。
模板方法模式的核心是“虚函数+final”组合
不是靠模板（template）实现的，名字里的“模板”指行为骨架固定、子类填充细节——本质是面向对象的控制反转。C++里靠基类定义final的公开接口，把可变部分声明为virtual纯虚函数，强制派生类实现。
常见错误是误用template写泛型函数去模拟，结果失去运行时多态和策略替换能力；或者忘了用final封住钩子调用顺序，导致子类意外重写主流程。
-
template方法名不能是虚函数，二者语法冲突 - 主流程函数必须
final，否则子类可能破坏执行顺序 - 纯虚函数命名建议带
do_前缀（如do_execute()），明确标识“这是你要填的空”
标准写法：基类封装流程，子类只管override虚函数
比如一个报告生成器：固定包含标题、正文、页脚三步，但每步内容由子类决定。基类不暴露generate()的实现细节，只提供最终调用入口。
template
- 若用
template写“通用流程”，每次实例化都生成新函数，无法统一管理策略对象 - 无法将不同子类对象存入同一容器（如
std::vector<:unique_ptr>>） - 调试时看不到实际调用链——所有
template展开都在编译期，堆栈里只剩具体实例名
容易忽略的细节：构造函数中不能调用虚函数
如果在基类构造函数里就试图触发do_generateContent()，哪怕子类已定义，调用的仍是基类版本（或未定义行为）。因为此时子类部分尚未构造完成。
典型陷阱代码：
ReportGenerator() {
generate(); // ❌ 危险！此时do_generateContent()不会调用子类实现
}
正确做法是显式要求用户调用generate()，或提供工厂函数延迟初始化。
真正难的不是写对语法，而是判断某个流程是否适合抽成模板方法——它得满足：步骤顺序固定、某些环节逻辑高度相似但数据/IO方式不同、且需要运行时切换策略。硬套反而增加继承深度和耦合。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
