crtp通过模板参数传递派生类类型，使基类在编译期获知完整派生类定义，借助static_cast直接调用其成员函数，实现零开销静态多态。
CRTP 怎么让编译期决定调用哪个函数
CRTP 的静态多态本质是「把派生类类型作为模板参数传给基类」，让基类里的 static_cast 在编译期就能拿到完整派生类定义，从而直接调用其成员函数，完全绕过虚函数表查找。
关键不在“继承”，而在“模板实例化时基类已知派生类的完整接口”。比如：
template <typename Derived>
struct Base {
void interface() { static_cast<Derived*>(this)->impl(); }
};
<p>struct MyWidget : Base<MyWidget> {
void impl() { /<em> 实际逻辑 </em>/ }
};这里 Base<mywidget>::interface()</mywidget> 内联展开后就是直接调用 MyWidget::impl()，零运行时开销。
- 必须确保
Derived在实例化Base<derived></derived>时已完全定义（不能是前置声明） - 基类中所有对派生类的调用，都得通过
static_cast<derived>(this)</derived>—— 少写一次就可能调到基类未定义的函数，链接失败或未定义行为 - 不能在基类构造函数里调用
static_cast<derived>(this)->impl()</derived>：此时派生类部分尚未构造，属于未定义行为
为什么 CRTP 比虚函数快，但又不是万能加速器
虚函数调用要查 vtable + 间接跳转，现代 CPU 预测失败时可能损失 10–20 个周期；CRTP 调用被内联后就是普通函数调用，甚至能进一步被编译器优化掉冗余计算。
但性能优势有前提：
- 编译器得能内联 —— 如果
interface()被声明为virtual或跨编译单元调用，内联失效，CRTP 白搭 - 派生类函数体不能太大，否则编译器主动拒绝内联，退化成普通函数调用（仍无虚调用开销，但失去定制化优化机会）
- 模板膨胀：每个派生类生成一份基类代码，二进制体积增长，可能影响指令缓存命中率 —— 在嵌入式或热路径极多的场景反而不利
CRTP 和普通模板继承容易混淆的坑
常见错误是把 CRTP 当成“更酷的泛型继承”来用，结果掉进类型系统陷阱。
立即学习“C++免费学习笔记（深入）”；
-
Base<derived></derived>和Base<other></other>是完全不同的类型，无法用统一指针/引用持有 —— 想做容器？得用类型擦除（如std::any）或变参模板，不是 CRTP 该干的活 - 基类里想访问派生类的
static成员？必须写成Derived::some_static_member，不能漏掉作用域；若该成员依赖模板参数，还得加template关键字（Derived::template get<int>()</int>） - VS 和 GCC 对不完全类型下
static_cast的诊断严格度不同：有些代码在 GCC 编译不过，在 VS 却静默通过，上线后崩溃
什么时候该用 CRTP，而不是 virtual 或 concept
CRTP 不是替代虚函数的通用方案，它只适合「编译期可枚举所有子类、且每个子类行为差异大、需要深度定制基类逻辑」的场景。
- 数值计算库（如 Eigen）：矩阵表达式模板靠 CRTP 把运算符重载链在编译期折叠，避免临时对象
- 策略类（policy-based design）：比如
allocator_policy、locking_policy作为模板参数注入，比运行时传策略对象更轻量 - 别硬套：如果子类行为只有微小差异（比如仅改一个阈值），用
const成员变量 + 普通继承更清晰；如果需要运行时切换行为，CRTP 直接不适用
最常被忽略的一点：CRTP 基类没法被单独实例化或前向声明使用，所有依赖它的接口都得是模板 —— 这会传染式地增加头文件耦合和编译时间。想清楚这个代价是否值得。
