CRTP基类必须显式接收派生类类型作为模板参数，否则导致编译失败或未定义行为；派生类须完整定义后才能实例化基类模板；CRTP不支持运行时多态，无法替代虚函数的全部能力，且易引发模板膨胀与编译开销。
CRTP基类必须显式接收派生类类型作为模板参数
CRTP不是普通继承，基类本身是模板，且模板参数必须是最终派生类。编译器靠这个参数在 Base<derived></derived> 中静态确定 Derived 的完整类型，才能做 static_cast<derived>(this)</derived> 安全转型。漏写模板实参、传错类型（比如传了中间基类）、或用 auto 替代具体类型，都会导致编译失败或未定义行为。
常见错误现象：
-
error: 'Derived' does not name a type—— 忘记在基类定义中声明模板参数 -
error: invalid static_cast from type 'Base<t>*' to type 'Concrete*'</t>—— 派生类没继承Base<concrete></concrete>，而是写了Base<void></void>或Base<t></t> - 运行时崩溃 ——
static_cast目标类型与实际对象不匹配（例如多重继承下布局异常，但 CRTP 通常不鼓励多重继承）
派生类必须完整定义后再实例化基类模板
因为 Base<derived></derived> 在实例化时要访问 Derived::implementation() 的签名甚至定义（尤其启用内联或 constexpr 时），所以不能在 Derived 声明但未定义完成前就让基类模板“看到”它。否则会触发 incomplete type 错误。
典型场景与处理方式：
- 头文件中定义基类模板 → 派生类定义必须在该头文件之后（或同一翻译单元内靠后位置）
- 想把派生类放在单独 cpp 文件？不行 —— CRTP 是编译期绑定，所有相关代码需可见；必须把派生类定义也放进头文件，或使用显式模板实例化（
template class Base<concrete>;</concrete>）并在 cpp 中提供实现 - 循环依赖？避免把
Base和Derived的定义互相嵌套；优先用前向声明 + 分离接口/实现，或改用函数模板重载替代部分 CRTP 场景
CRTP无法替代虚函数的全部能力：没有运行时类型擦除
CRTP 实现的是“单态调用”，即每个 Base<t></t> 实例只对应一种 T，不能像 std::unique_ptr<shape></shape> 那样持有不同派生类对象并统一调用。你无法用 std::vector<base>> 存多种派生类——模板参数不同就是完全不同的类型，不兼容。
如果真需要运行时多态混合行为，只能组合使用：
- 内部用 CRTP 做高性能核心逻辑（如数学运算、序列处理）
- 外层再包一层虚接口（如
class Drawable { virtual void draw() = 0; };），由 CRTP 派生类继承该虚基类，实现桥接 - 或者放弃统一容器，改用
std::variant<circle rect triangle></circle>+std::visit，保持零成本抽象同时支持有限枚举类型
模板膨胀与编译时间代价不可忽视
每种派生类都会生成一份独立的 Base<t></t> 实例代码，包括所有非内联成员函数。若基类有 10 个方法，而你有 50 个派生类，就可能生成 500 份相似代码段，显著增加二进制体积和编译耗时。
缓解策略：
- 把通用逻辑尽量抽到非模板辅助类或自由函数中，CRTP 基类只保留调度胶水代码
- 对大函数体禁用内联（加
[[gnu::noinline]]或 MSVC 的__declspec(noinline)），让链接器有机会合并相同机器码 - 检查
nm -C your_binary | grep Base | wc -l，确认模板实例数量是否失控
真正难处理的不是语法，是权衡：当接口稳定、派生类数量可控、性能压倒一切时，CRTP 是利器；一旦需要灵活扩展、动态加载或跨模块复用，它反而会成为维护负担。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
