17370845950

CRTP通过模板参数在编译期绑定派生类类型，实现零开销静态多态，避免虚函数表的间接调用、缓存不友好和不可内联问题，适用于类型关系确定的场景。

虚函数表（vtable）带来间接调用开销、缓存不友好和无法内联等问题。若多态行为在编译期已知，CRTP（Curiously Recurring Template Pattern）可实现零开销静态多态，彻底规避 vtable。

CRTP 基本写法：把派生类作为模板参数传给基类

基类是模板，接收子类类型；子类继承时显式传入自身类型。这样基类能“静态知道”最终类型，所有调用都在编译期绑定。

示例：

template 
struct Base {
    void interface() {
        static_cast(this)->impl(); // 静态分发，无虚表
    }
};
struct MyWidget : Base {
void impl() { / 具体实现 / }
};

调用 MyWidget{}.interface() 会直接跳转到 MyWidget::impl，无查表、无指针解引用、可被编译器内联。

替代虚函数接口：用 CRTP 实现策略/行为注入

当原设计依赖抽象基类（如 Renderer、Logger），可用 CRTP 拆出策略模板，避免运行时多态。

• 把“接口函数”变成基类模板中的普通成员函数，内部调用 static_cast::xxx()
• 不同策略通过不同派生类实现，编译期选择，不共享 vtable
• 支持组合：一个类可同时继承多个 CRTP 基类（如 BaseLog + BaseSerialize）

注意 CRTP 的适用边界

CRTP 不是万能替代，它只适用于**编译期确定类型关系**的场景：

• 不能用于运行时才决定对象类型的场合（比如从配置加载插件、用户输入选择算法）
• 无法通过基类指针/引用来统一持有不同派生对象（没有公共非模板基类）
• 模板实例膨胀：每个派生类生成独立基类副本，可能增加代码体积（但换来速度）
• 错误信息可能变长，需配合 static_assert 和 concepts 提升可读性

混合使用：CRTP + 少量虚函数兜底

真实项目中常采用分层策略：

• 核心热路径（如数学计算、粒子更新、渲染循环内）用 CRTP 实现静态多态
• 扩展点或插件系统保留虚函数接口，牺牲一点性能换取灵活性
• 用 final 修饰叶节点类，帮助编译器进一步优化虚调用（即使有虚函数，也可禁用进一步继承）

基本上就这些。CRTP 不是语法糖，它是用模板元编程把“多态决策”前移到编译期的明确手段——只要类型关系固定，它就能消灭 vtable 开销，且比手动函数指针更安全、更易维护。