模板方法模式本质是“虚函数+final”实现的面向对象控制反转，非C++模板；基类用final封主流程、纯虚函数留钩子，子类仅override do_前缀虚函数。
模板方法模式的核心是“虚函数+final”组合
不是靠模板（template）实现的，名字里的“模板”指行为骨架固定、子类填充细节——本质是面向对象的控制反转。C++里靠基类定义final的公开接口，把可变部分声明为virtual纯虚函数，强制派生类实现。
常见错误是误用template写泛型函数去模拟，结果失去运行时多态和策略替换能力；或者忘了用final封住钩子调用顺序，导致子类意外重写主流程。
-
template方法名不能是虚函数，二者语法冲突 - 主流程函数必须
final，否则子类可能破坏执行顺序 - 纯虚函数命名建议带
do_前缀（如do_execute()），明确标识“这是你要填的空”
标准写法：基类封装流程，子类只管override虚函数
比如一个报告生成器：固定包含标题、正文、页脚三步，但每步内容由子类决定。基类不暴露generate()的实现细节，只提供最终调用入口。
class ReportGenerator {
public:
void generate() final { // 不能被重写
printHeader();
do_generateContent(); // 纯虚，子类必须实现
printFooter();
}
protected:
virtual void do_generateContent() = 0; // 钩子函数
void printHeader() { std::cout << "=== REPORT ===\n"; }
void printFooter() { std::cout << "=== END ===\n"; }
};
派生类只需关注业务逻辑：
立即学习“C++免费学习笔记（深入）”；
class HTMLReport : public ReportGenerator {
protected:
void do_generateContent() override {
std::cout << "<p>HTML content</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/gongju/2823" title="C++14">C++14</a>
<p>C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div>\n";
}
};
为什么不用template？它解决的是另一类问题
template解决编译期类型泛化，比如std::sort适配任意可比较类型；而模板方法模式解决的是**运行时算法骨架复用**，需要动态绑定和继承体系支持。
- 若用
template写“通用流程”，每次实例化都生成新函数，无法统一管理策略对象 - 无法将不同子类对象存入同一容器（如
std::vector<:unique_ptr>></:unique_ptr>） - 调试时看不到实际调用链——所有
template展开都在编译期，堆栈里只剩具体实例名
容易忽略的细节：构造函数中不能调用虚函数
如果在基类构造函数里就试图触发do_generateContent()，哪怕子类已定义，调用的仍是基类版本（或未定义行为）。因为此时子类部分尚未构造完成。
典型陷阱代码：
ReportGenerator() {
generate(); // ❌ 危险！此时do_generateContent()不会调用子类实现
}
正确做法是显式要求用户调用generate()，或提供工厂函数延迟初始化。
真正难的不是写对语法，而是判断某个流程是否适合抽成模板方法——它得满足：步骤顺序固定、某些环节逻辑高度相似但数据/IO方式不同、且需要运行时切换策略。硬套反而增加继承深度和耦合。
