多态这两个字，几乎每一条 C++ 学习路线上都会出现，但它也是最容易被"背概念"糊弄过去的一块。我见过太多人能把"父类指针指向子类对象，调用同名函数走子类实现"这句话背得滚瓜烂熟，可一旦代码在真实项目里跑出意料之外的结果——析构函数没被调用、虚函数死活不生效、release 版本行为和 debug 不一致——就完全不知道从哪儿下手。这篇笔记不打算复述教材，而是把 C++ 多态从语言规则到内存布局、从常见陷阱到替代方案，按我自己踩坑的顺序重新捋一遍。内容覆盖虚函数表、虚析构、override、对象切片、RTTI、CRTP 与 std::variant 这些实打实的点，适合已经会写类、但对"为什么这么写"还含糊的朋友，也适合想回头补底层细节的老手。看完你至少应该能做到：看到一段多态代码，脑子里能浮现出对象的内存图和那次间接调用的路径。
1. 多态到底在解决什么问题，先把账算清楚
1.1 从一段"能编译、能跑、但结果是错的"代码说起
我最早接触多态，是在做一个图形绘制的小练习。当时的需求很朴素：一个容器里放各种图形，循环调用 draw() 把它们画出来。很自然就写成了基类 Shape 加派生类 Circle、Rect，然后声明std::vector<Shape>往里塞对象。代码编译通过，运行也不崩，但屏幕上只出现了一堆基类的默认图形，派生类的特有部分全没了。
这个坑就是对象切片。std::vector<Shape>里存的是 Shape 类型的完整对象，当你把一个 Circle 塞进去，编译器会调用 Shape 的拷贝构造函数，只把 Circle 中属于 Shape 的那部分子对象复制过去，Circle 新增的成员、重写的虚表指针全被切掉。容器里躺着的自始至终都是 Shape，多态自然无从谈起。
改成std::vector<std::unique_ptr<Shape>>之后一切正常。这个改动看着只是换了容器元素类型，本质却是把"值语义"换成了"引用语义"——多态依赖的是运行期通过指针或引用找到真实类型，一旦按值复制，类型信息在拷贝那一刻就丢了。我在后续很多项目里反复验证过这条规律：多态只活在指针和引用上，值传递是它的天敌。这也是为什么接口类通常要禁用拷贝构造，或者干脆声明成抽象类。
顺带说一个相关的隐蔽版本：函数参数写成void render(Shape s)，调用时传 Circle，一样会切片。这种问题编译器不会给任何警告，只能靠编码规范去堵——接口参数一律用const Shape&或Shape*。
1.2 静态绑定和动态绑定的分界线在哪
理解多态，核心是搞清楚"这次调用到底在什么时候确定"。C++ 里绝大多数函数调用是静态绑定：编译器看到调用点，根据变量的静态类型直接生成一条 call 指令，跳到固定地址。而非虚函数、全局函数、静态成员函数、模板实例化出来的函数，全都走这条路。它们的优点是零额外开销，能被内联，能被编译器做各种优化。
动态绑定只发生在一种情况下：通过指针或引用调用虚函数，且编译器无法确定对象的动态类型。这时编译器生成的不是直接跳转，而是"先找到对象的虚表指针，再从表里取出函数地址，最后间接调用"。这个查找过程发生在运行时，具体跳到哪个函数，取决于对象真正的类型。
两者的差别用一个类比讲最清楚。静态绑定像你按门牌号找人，地址写死在纸条上，纸上写几号就去几号；动态绑定像你先找到这个人的档案柜（虚表指针），再按档案编号（虚表下标）取出联系方式，人换了柜子里的卡片就跟着换。前者快但死板，后者慢一点但灵活。
这里有个常被忽略的细节：即使函数是虚的，只要编译器能确定对象的动态类型，它依然会做静态绑定。比如Circle c; c.draw();中 c 是确切的对象而非指针引用，编译器直接调 Circle::draw。这种"去虚化"（devirtualization）在开启优化后经常出现，也是为什么有些性能测试里虚函数看起来"没开销"——被测代码根本没走虚表。想知道真实开销，必须让调用点通过基类指针进行，并且跨编译单元，防止编译器看穿。
1.3 多态带来的三个真实收益
很多人学完多态只觉得"哦，就是父类指针调子类方法"，说不上它到底值钱在哪。我按实际项目里的体会，归纳成三条。
第一条是调用方与实现的解耦。上层代码只依赖基类接口，新增一种实现时，调用方的代码一行不用改。这在插件式架构里是刚需：主程序编译好之后，新功能以动态库形式加载进来，只要遵守同一个抽象接口，主程序完全不感知。如果没有多态，你就得在调用点写一长串 if-else 或者 switch，每加一种类型就动一次核心代码，回归测试范围越滚越大。
第二条是统一的生命周期管理。一堆异构对象放在同一个容器里，通过基类指针统一析构，这是多态配合虚析构最实用的场景。资源释放、状态清理这些逻辑可以写在基类析构里，派生类只管自己那部分，不会漏。
第三条是行为的可替换性。同一份算法流程，换一个策略对象就换一套行为，这是策略模式、状态机、访问者模式的基础。比如一个数据处理的流水线，读入、清洗、输出三步都定义成抽象接口，测试时注入 Mock 实现，生产时注入真实实现，业务代码完全不用改。
不过我也得说句实话：多态的收益不是无条件的。如果类型集合是封闭的、编译期就知道全部可能，用多态反而是过度设计，一个 enum 加 switch 更直白，性能也更好，还能让编译器帮你检查分支是否覆盖完整。选不选多态，取决于"未来会不会有新类型加进来"这个判断。
2. 虚函数在内存里长什么样
2.1 虚表与虚表指针的基本布局
要真正把多态吃透，必须知道编译器在背后干了什么。主流实现（GCC、Clang 用的 Itanium ABI，MSVC 的布局略有差异但思路一致）是这样的：每个含虚函数的类，编译器为它生成一张虚函数表，表里按声明顺序存放该类各个虚函数的地址。这张表是类级别的，全局只有一份，放在只读数据段。
每个对象则在内存里多出一个隐藏的指针，通常叫 vptr，指向所属类的虚表。这个指针一般放在对象起始位置，占一个机器字长（64 位下 8 字节）。也就是说，一个"什么都没有"的空类本来 size 是 1，一旦加了虚函数，对象立刻膨胀到 8 字节；再加一个 int 成员，按对齐规则会变成 16 字节。
这个开销在小对象上非常显著。我做过一个对比：一个只含两个 int 的配置结构体，加虚函数之前 8 字节，加之后 16 字节，翻倍。如果这个对象要在容器里存上百万个，内存占用直接翻番，缓存命中率也会掉。所以有一条经验：数据密集的小结构体不要随便加虚函数，虚函数适合放在行为抽象层，不适合放在高频的数据载体上。
再补一个容易混淆的点：vptr 不是 static 成员，它是每个对象各自持有的。同一类的所有对象，vptr 的值相同（都指向同一张表）；不同类型的对象，vptr 不同。这就是运行时能识别类型的物理基础。
2.2 一次虚函数调用的完整路径
把调用拆开看，一次p->draw()大致经过这么几步：
- 从
p指向的对象内存里，读出起始位置的那个指针（vptr）； - 编译器在编译期已经知道 draw 在虚表里的槽位下标（比如第 0 个），于是用
vptr + 0 * 8算出表项地址； - 从该地址取出函数指针；
- 通过这个指针做间接调用，同时把
p作为 this 传进去。
用伪代码写出来大概是(*(p->vptr[0]))(p)的形式。这里有个关键点：槽位下标是编译期固定的。编译器在编译基类时就给每个虚函数分配了固定位置，派生类重写时必须把新函数放在同一个槽位，这样基类代码用固定下标取函数才能取对。如果派生类新增了虚函数，那就往表后面追加，不能插在中间——插在中间会让基类代码算出的偏移全部错位。这也解释了为什么虚表布局一旦定下来就不能随意改动，二进制兼容性对 C++ 库来说是个老大难问题。
还有一点值得注意：调用把 p 作为 this 传进去时，如果派生类对象里的基类子对象不在起始位置（多继承时会出现），编译器会插入一小段代码调整指针，这段代码通常叫 thunk。所以多继承下的虚函数调用，开销比单继承多一次指针加法。写代码时感知不到，但在极端性能敏感的循环里是实打实的差异。
2.3 单继承、多继承、虚继承下的表结构差异
单继承最简单：派生类共享基类的虚表布局，重写就替换槽位里的地址，新增就往后追加。派生类对象里只有一个 vptr，指向自己的虚表。
多继承就有意思了。假设 Derived 同时继承 Base1 和 Base2，两者都有虚函数。此时 Derived 对象里会有两个 vptr：第一个继承自 Base1 的子对象（通常在对象起始位置），第二个属于 Base2 的子对象（在偏移位置）。把 Derived* 转成 Base2* 时，指针值会变化，加一个偏移量，因为 Base2 子对象不在对象头部。这也是为什么static_cast在多继承下不能简单理解为"指针值不变"。
虚继承（菱形继承里常见）更复杂，会额外引入虚基类表指针或者偏移信息，用来在运行期定位那份唯一的虚基类子对象。我第一次碰到虚继承是在一个老项目里，某个类继承了两个都继承自同一基类的中间类，结果 sizeof 出来的对象比预期大了一圈，查了半天才发现是虚基类偏移表带来额外开销。
这里给个实操建议：多继承尽量只用于"一个实现类 + 多个纯接口"的组合。接口类没有数据成员，只有一个 vptr 和纯虚函数，布局代价小，职责也清楚。真正棘手的多继承状态冲突，基本都出现在两个基类都有数据成员的场景，这种设计在绝大多数业务里都没必要。
2.4 虚函数的性能代价到底有多大
网上的说法从"几乎没开销"到"慢十倍"都有，我自己测过几轮，结论是：单次虚函数调用的绝对开销在纳秒量级，跟一次普通函数调用相比大概多几纳秒，差距主要体现在三个方面。
第一是多了一次内存间接寻址。vptr 在对象里，虚表在只读段，函数地址又是间接取的，这几跳如果都不在缓存里，就是若干次 cache miss，耗时会被放大。第二是阻止内联。普通函数小到一定程度编译器就内联了，虚函数因为目标不定，除非去虚化否则内联不了，原本可以省略的函数调用开销就全留下来了。第三是影响分支预测和指令缓存，间接跳转的目标不固定，CPU 的分支预测器容易猜错。
我把这三条落成一张对照表：
| 场景 | 相对开销 | 主要原因 |
|---|---|---|
| 静态绑定的小函数，可内联 | 基准 | 编译器直接把函数体摊平 |
| 虚函数调用，对象在缓存中 | 约 1.2 到 2 倍 | 多一次间接寻址，无法内联 |
| 虚函数调用，对象分散在堆上 | 可能数倍 | vptr 与虚表频繁 cache miss |
| 多继承下的虚函数调用 | 略高于单继承 | 需要 this 指针调整（thunk） |
| 构造函数中调用虚函数 | 不会走虚表 | 构造期间 vptr 指向当前正在构造的类 |
结论不是"虚函数很慢"，而是虚函数在热点路径上要谨慎。一个每帧调用几万次的渲染循环，如果每次都是虚调用，开销就不可忽略；而一个每秒调用几十次的事件分发，用虚函数完全没问题。我在优化过一个音视频处理回调后得到的经验是：把最内层的逐样本处理从虚函数改成模板参数或者函数指针数组，实测能省下可观的 CPU 时间；外层框架保留虚接口，可读性不受影响。
3. 虚函数的关键规则与实操要点
3.1 虚析构函数为什么是硬性要求
这是多态里最容易出事故的一条规则，没有之一。只要一个类可能被基类指针 delete，它的析构函数就必须是虚的。
原因在于析构调用的绑定规则和普通虚函数一样。如果析构不是虚的，delete base_ptr会按静态类型调用 Base 的析构函数，派生类析构函数根本不会执行，派生类里 new 出来的成员全部泄漏。更糟的是，如果派生类对象在分配时用的内存大小和基类不同（比如派生类更大），释放的地址和大小都可能不对，直接是未定义行为。
代码写出来很简单，但事故往往很隐蔽：
class Base { public: ~Base() { } // 销毁时不调用派生类析构 }; class Derived : public Base { public: ~Derived() { delete[] buffer; } private: char* buffer = new char[1024]; }; Base* p = new Derived(); delete p; // Derived::~Derived 不会执行，buffer 泄漏把~Base()改成virtual ~Base()就解决了。我的习惯是：只要类里有任何一个虚函数，析构函数立刻标 virtual，不管当前有没有派生类。这条规矩机械执行就好，不需要每次去推演"这个类会不会被继承"。
有个反过来的坑也得提：如果基类不打算被多态使用（没有虚函数），千万不要随手加虚析构。加了之后对象凭空多 8 字节，布局变了，如果这个类型要和 C 接口或者其他语言交互，内存布局对不上会出大问题。我们在一个跨语言数据交换的结构体上就吃过这个亏，加了虚析构之后对面按字节解析直接错位。
3.2 override 和 final 值得无脑加上
C++11 引入的override关键字，作用是在编译期检查"这个函数确实覆盖了基类的虚函数"。它的价值远超"语法糖"这个定位——签名不匹配导致的"假覆盖"是多态失效的头号原因。
想象基类有virtual void update(int value)，你在派生类写了void update(float value)。在编译器眼里，这两个是完全不同的函数，派生类的那个只是个新增的非虚函数，基类的虚函数没有被覆盖。通过基类指针调用时，走的还是基类版本，而且没有任何编译警告。我见过一个线上问题就是参数类型从 int 改成 double 之后没同步改派生类，结果覆盖静默失效，排查了大半天。加上override之后，这种情况会直接编译报错。
容易导致签名不一致的几个点，我列一下：const 修饰符（draw()和draw() const是不同的函数，这一点最阴）、参数类型的隐式转换（int 和 long 不算同一个）、返回类型（除非是协变）、引用限定符（&和&&）。建议团队规范直接写死：所有重写虚函数一律加 override。
final则有两个用途。一是标记某个虚函数不允许再被派生类覆盖，二是标记某个类不允许被继承。除了表达设计意图，它还有个实际好处：帮助编译器去虚化。编译器看到 final 就能确定"这就是最终实现"，可以放心把虚调用替换成直接调用甚至内联。在一些性能敏感代码里，加 final 是零成本的优化手段。
3.3 构造和析构函数里调用虚函数会发生什么
这个问题面试常考，但很多人记住的是"不会多态"，说不清为什么。
原因就在 vptr 的更新时机。对象构造时，vptr 不是一开始就指向最终派生类的虚表。执行顺序是：先构造基类子对象，此时 vptr 被设置为基类的虚表；基类构造完成后，vptr 才被更新为派生类的虚表；然后执行派生类构造函数体。所以如果基类构造函数里调用了虚函数，走的是基类版本，因为那时对象"还只是个基类"。
这个设计的合理性在于：派生类的成员还没初始化，如果那时候调用派生类的重写版本，函数体里访问成员变量就是访问未初始化内存，属于未定义行为。编译器选择调用基类版本，是一种保护。
析构时顺序相反，vptr 先回退到当前正在析构的类。所以析构函数里调虚函数，同样只到当前类这一层。
代码验证一下：
class Base { public: Base() { hello(); } virtual ~Base() { hello(); } virtual void hello() { std::cout << "Base\n"; } }; class Derived : public Base { public: void hello() override { std::cout << "Derived\n"; } }; Derived d; // 输出两次 Base，不是 Derived更严重的版本是：如果基类构造函数里调用的是一个纯虚函数，那就是未定义行为，通常表现为运行期崩溃（虚表槽位里是空指针或者指向一个桩函数）。我在一个框架代码里就见过有人在基类构造函数里调用init()，而 init 是纯虚的，本地 debug 能跑是因为编译器放了个占位函数，release 下直接崩，这种问题复现环境极难对齐。
实操建议很简单：构造和析构里不要依赖虚函数，需要"对象就绪后初始化"的，抽一个initialize()方法由外部显式调用，或者用两段式构造配合工厂函数。
3.4 默认参数和协变返回值这两个隐藏雷区
默认参数是静态绑定的，这一点跟虚函数机制完全无关。看这段：
class Base { public: virtual void show(int level = 1) { std::cout << "Base " << level; } }; class Derived : public Base { public: void show(int level = 2) override { std::cout << "Derived " << level; } }; Derived d; Base* p = &d; p->show(); // 输出 "Derived 1"函数体走的是派生类版本（动态绑定生效），但默认值 1 是从基类声明里取的（静态绑定）。这种"半动态半静态"的结果最容易让人误判。结论：虚函数尽量不要带默认参数，非要带，就保证整个继承链上默认值一致，或者干脆把参数显式传进去。
协变返回类型相对温和些。它允许派生类重写虚函数时返回一个更具体的类型，前提是基类返回指针或引用，且派生类返回的类型能转换成基类返回的类型。经典写法是virtual Base* clone() const，派生类重写成Derived* clone() const override。这在原型模式里很好用，能避免调用方再 static_cast。注意它只对指针和引用有效，返回值的场景行不通。
3.5 访问控制和虚函数的关系也值得说一句
有个反直觉的点：基类的虚函数可以是 private 的，派生类照样能覆盖它。覆盖时访问级别可以放宽也可以收紧。但如果调用方是通过基类指针调用，那就受基类的访问控制约束——基类把它设成 private，外部根本调不到，哪怕派生类设成了 public。
这个特性在做非虚接口（NVI）模式时特别好用：基类把run()设为 public 的非虚函数，内部调用 private 的虚函数doRun()，派生类只覆盖 doRun。这样所有前置检查、后置处理都能固定在基类里，派生类没法绕过，也没法改变调用契约。模板方法模式就是这么落地的，比让调用方直接覆盖虚函数要稳得多。
4. 纯虚函数、抽象类与接口设计
4.1 纯虚函数不是"没有实现"
virtual void foo() = 0;这个语法很多人以为等价于"这个函数没有函数体"，其实纯虚函数完全可以有定义，只是不能在类内部定义，要在类外写。派生类如果要实例化，必须覆盖它；但派生类在覆盖的实现里可以显式调用Base::foo()，这就用到了那份定义。
纯虚析构的情况更特殊：纯虚析构必须有定义。因为派生类析构时会自动调用基类析构，如果基类析构只有声明没有定义，链接期就报未定义符号。这个坑我踩过，而且是链接错误而不是编译错误，报错信息指向的位置还很有迷惑性。正确写法：
class Interface { public: virtual ~Interface() = 0; // 声明为纯虚，阻止直接实例化 }; Interface::~Interface() = default; // 必须提供定义纯虚析构的用处是：当你想让类成为抽象类，但又没有其他合适的函数可以设计成纯虚时，就把析构设成纯虚。不过我个人更倾向于显式写一个纯虚的init()或者把某个业务函数设为纯虚，语义更清楚。
4.2 接口类设计的三条经验
写接口类，我有几条几乎无脑照做的规矩。
第一条：接口类不持有数据成员，析构设为 public virtual 或者 protected 非虚。前者适合外部会 delete 的场景，后者适合"对象由工厂创建、由工厂销毁"的场景，能防止用户误用 delete。protected 非虚析构的意思是：不允许通过基类指针 delete，但派生类析构照常被调用。这个是 C++ 核心准则里推荐的写法，安全性上其实更高。
第二条：接口方法尽量不返回裸指针，返回std::unique_ptr或者引用，把所有权表达清楚。裸指针的返回值意味着"这个指针是谁的、要不要释放"全靠文档，多态体系里这个模糊点会被放大。
第三条：接口粒度要小。一个接口塞二十个方法，实现类哪怕只关心其中三个也得全部实现（要么写一堆空实现）。我更倾向于拆成多个小接口，实现类按需继承，调用方也能清楚表达"我只需要这个能力"。这在跨模块依赖时尤其重要，接口太大意味着依赖面太大，编译时间长、改动波及广。
再补一条实际的：接口里别用std::string、std::vector这类标准库类型做参数，除非你确定所有使用者用同一个编译器版本、同一套 STL 实现，且二进制兼容。跨动态库边界时，标准库类型的 ABI 一致性是个大坑，我见过因为一侧开了 debug 迭代器、另一侧没开，导致传 vector 直接崩溃的案例。要在边界上传递，用 C 风格的结构体加长度字段最稳。
4.3 对象切片和值语义陷阱再展开一点
前面提过切片，这里补充几个更隐蔽的变体。
把派生对象赋值给基类对象是显式的切片，编译器不会拦。Base b = derived;这行代码合法，但 derived 的额外状态全部丢失。要禁止这种事，最直接的办法是让基类成为抽象类，抽象类根本不能实例化，切片自然无从发生。
用基类容器存派生对象是隐式切片，前面说的std::vector<Base>就是。换成std::vector<std::unique_ptr<Base>>或者std::vector<std::reference_wrapper<Base>>都行。前者管理所有权，后者不管理。
按值传参和按值返回也都会切片。Base make()返回一个 Derived 对象，返回的其实是基类部分。函数参数写成基类值类型，传派生对象进去也一样。
还有一种是异常捕获。catch (BaseException e)捕获的是值，如果抛出的是 DerivedException，异常对象会被切片成 BaseException，派生部分的附加信息（比如错误码、上下文）全丢。正确写法是catch (const BaseException& e)。这条在写异常体系时特别关键，异常类型通常带一堆诊断信息，切片等于把诊断信息扔了。
我把这几种情况汇总一下，方便对照：
| 场景 | 是否切片 | 推荐写法 |
|---|---|---|
Base b = derived; | 是 | 基类设为抽象类，或禁用拷贝 |
std::vector<Base> | 是 | 存unique_ptr<Base>或reference_wrapper |
void f(Base b) | 是 | 改const Base& |
Base f()返回派生对象 | 是 | 返回unique_ptr<Base> |
catch (Base e) | 是 | 改catch (const Base& e) |
Base* p = new Derived; | 否 | 正常用法，注意虚析构 |
5. RTTI：运行期知道对象是谁
5.1 typeid 的行为边界
typeid的行为取决于表达式是不是多态类型。对非多态类型（没有虚函数的类、基本类型），typeid在编译期就确定结果，和运行时的对象没关系；对多态类型，typeid会走虚表去取实际类型信息，返回动态类型。
struct Plain { }; struct Poly { virtual ~Poly() = default; }; struct Sub : Poly { }; Sub s; Plain& r1 = s; // 编译报错，类型无关 Poly& r2 = s; std::cout << typeid(r2).name(); // 输出 "Sub"一个必须注意的边界：typeid(*ptr)如果 ptr 是空指针，会抛出std::bad_typeid。而typeid(ptr)只是取指针本身的类型，不会解引用，所以安全。这个差异很容易写错。
另外typeid(...).name()返回的字符串是实现定义的，GCC 下会带长度前缀且经过名字修饰（比如3Sub），可读性很差。要拿到可读名字，得用abi::__cxa_demangle或者干脆不用 name() 做逻辑判断。更重要的是：永远不要用类型名字符串做逻辑分支，不同编译器、不同版本的结果都不一样，这种代码换平台就崩。
5.2 dynamic_cast 的代价与替代思路
dynamic_cast是带运行时检查的向下转型。指针版本失败返回 nullptr，引用版本失败抛std::bad_cast。它在继承图里逐层比较类型信息，比 static_cast 慢不少，而且要求源类型是多态的（有虚函数），否则编译不过。
它最实用的场景是：手里有个基类指针，想知道它到底是不是某个具体类型，是的话安全地转过去做特定操作。比如一个事件系统里，基类 Event 指针进来，先判断是不是 KeyboardEvent，是就走键盘处理逻辑。
但我在实际项目里越来越倾向于少用 dynamic_cast。原因有两个：一是它把类型判断散落在调用方，每加一种类型就要在所有判断点加分支，本质上是把 switch 藏在了各个角落；二是性能不可控，尤其嵌套在循环里。
替代方案我常用三种：一是在基类加一个类型标签枚举，配一个虚函数返回它，判断枚举值再 static_cast，速度快很多，代价是要手动维护枚举；二是双重分发，也就是访问者模式，把"根据类型做不同处理"这件事收敛到一个地方，新增类型时编译器会逼着你补全所有分支；三是把差异做成虚函数，让每个类型自己实现行为，调用方根本不需要知道类型。方案三最优，只有在确实需要按类型分支时才考虑前两种。
还有一点：如果项目编译时加了-fno-rtti，dynamic_cast 和 typeid 都用不了。一些嵌入式或者对二进制体积敏感的项目会关掉 RTTI，这时就得靠自定义类型标签。
6. 静态多态：不开虚表的另一条路
6.1 CRTP 的写法与适用边界
CRTP 的全称是奇异递归模板模式，写法是把派生类作为模板参数传给基类：
template <typename Derived> class ShapeBase { public: void draw() const { static_cast<const Derived*>(this)->drawImpl(); } }; class Circle : public ShapeBase<Circle> { public: void drawImpl() const { /* 具体绘制 */ } };因为 Derived 在编译期就确定了，static_cast是零开销的，drawImpl完全可以内联，整个调用链没有任何间接跳转。这是它相对虚函数最大的优势——性能上等价于手写代码。
代价也很明显。第一，没法做异构容器：ShapeBase<Circle>和ShapeBase<Rect>是两个完全无关的类型，塞不进同一个 vector。第二，编译期膨胀：每种派生类型都会实例化一份基类模板，类型多了会显著增加编译时间和二进制体积。第三，错误信息难看：模板报错本来就长，CRTP 的错误信息更是灾难，一个签名写错能刷出上百行。
我的判断标准是：类型集合在编译期完全确定、且性能敏感的时候用 CRTP，比如数值计算库里的表达式模板、序列化框架里的字段访问器。需要运行期动态加载、插件式扩展的场景，老老实实用虚函数。
6.2 std::variant 加 std::visit 的现代写法
C++17 之后多了一个很好的选择：std::variant。它是类型安全的联合体，把几种类型中的一个装在一个值里，配合std::visit做分发。
using Shape = std::variant<Circle, Rect, Triangle>; Shape s = Circle{}; std::visit([](const auto& shape) { shape.draw(); }, s);它的特点和虚函数正好互补：值语义（可以直接存容器、可以拷贝）、没有堆分配、大小固定（等于最大成员的大小）、分发可以内联。适合"类型集合封闭、不需要运行期扩展"的场景，比如解析器的 AST 节点、协议消息类型。
缺点是类型集合一旦定了就不好扩展，加一种类型要重新编译所有用到 visit 的地方，而且对象大小被最大成员撑大，成员尺寸差异大时很浪费空间。另外 visit 里的 lambda 必须对所有类型都能编译，某些类型不需要处理时得写个空实现或者用 if constexpr 过滤。
6.3 动态多态和静态多态怎么选
这张表是我自己在做技术选型时用的，贴在下面供参考：
| 维度 | 虚函数动态多态 | CRTP 静态多态 | std::variant |
|---|---|---|---|
| 调用开销 | 一次间接调用，阻止内联 | 零开销，可内联 | 通常可内联 |
| 对象大小 | 多一个 vptr | 不增加 | 等于最大成员 |
| 是否支持异构容器 | 支持（存指针） | 不支持 | 支持（同类型容器） |
| 运行期扩展 | 支持，可动态加载 | 不支持 | 不支持 |
| 编译时间 | 低 | 高，随类型数增长 | 中等 |
| 错误信息友好度 | 好 | 差 | 中等 |
| 典型场景 | 插件、框架接口、跨模块 | 数值库、高频调用 | 封闭类型集合、值语义 |
我个人的取舍是：跨模块边界、需要动态加载的用虚函数；模块内部的高频路径，如果类型封闭就考虑 variant 或者 CRTP。三者不是互斥的，一个系统里完全可以外层用虚接口，内层用 variant 加速。
7. 常见问题速查与排查手法
7.1 虚函数失效的排查清单
多态出问题，绝大多数情况逃不出下面这几类。我按排查顺序整理成表：
| 现象 | 最可能的原因 | 排查动作 |
|---|---|---|
| 调用的始终是基类版本 | 派生类函数签名不匹配，没构成覆盖 | 给派生类函数加override，看是否编译报错 |
| 同上 | 基类函数忘了写 virtual | 检查基类声明，注意派生类里同名函数不会自动变虚 |
| 同上 | 通过值传递的对象调用 | 检查函数参数是不是Base而非Base& |
| 同上 | 在构造/析构函数里调用 | 改到初始化方法里调用 |
| 析构时派生类资源没释放 | 基类析构不是虚的 | 加virtual，或用unique_ptr<Base>配合虚析构 |
| 新增虚函数后行为异常 | 动态库与主程序编译的类定义不一致 | 检查头文件版本，确认虚表布局一致 |
| release 崩、debug 正常 | 构造函数里调用了纯虚函数 | 移除该调用，改两段式初始化 |
| 类型判断总是走错分支 | 用了typeid但类型不匹配，或切片导致类型丢失 | 确认对象未被切片，typeid作用于多态类型的引用 |
7.2 几个我常用的土办法
打印 vptr 地址验证类型。在调试时，把对象前 8 字节当指针打出来，同一类型的对象应该打出相同的值，不同类型的应该不同。如果两个本该不同的对象打出了相同的 vptr，基本可以确定发生了切片或者对象被错误地按基类构造。
用编译器导出类布局。GCC 有个选项可以把类的内存布局和虚表内容 dump 出来，Clang 也有类似的。在怀疑布局对不上时，直接看编译器给出的虚表槽位和偏移，比猜快得多。
用 nm 或 objdump 看符号。动态库加载出问题时，看看导出的虚函数符号是否齐全，名字修饰后的符号能直接反映参数类型，签名不匹配在这里一目了然。
临时把虚函数改成纯虚。如果某个派生类本该覆盖却写错了签名，把它改成纯虚之后，编译器会明确告诉你"这个类没有实现纯虚函数"，报错位置直指问题。这是个很快的排除法，比一行行读代码高效。
加断言检查动态类型。调试版本里在关键接口入口加一句类型断言，能第一时间发现调用方传错了对象。上线前用宏关掉即可。
7.3 几条写多态代码的习惯
第一条，基类的析构要么 public virtual，要么 protected 非虚，二选一，不要留裸的 public 非虚。
第二条，所有重写函数都加 override，这一条能消灭掉大半的低级错误，成本几乎为零。
第三条，接口参数一律用引用或指针，禁止按值传多态类型。这条可以写进代码规范，靠 code review 守。
第四条，不要在构造和析构里调用虚函数，需要初始化就用工厂函数或者显式的 init 方法。
第五条，接口类禁止拷贝构造和拷贝赋值，= delete掉，防止隐式切片。移动操作也一并考虑清楚是否要禁用。
第六条，跨模块边界不要传 STL 类型，用 POD 结构体加长度字段，避免 ABI 不一致带来的玄学崩溃。
第七条，热点路径上的虚调用要实测，别凭感觉优化。先去 profile，确认它真的是瓶颈再动手，很多时候瓶颈在别处，把虚函数改成 CRTP 只是把代码搞复杂了。
我在实际项目里的体会是，多态带来的复杂度主要不在语法，而在"什么时候不该用它"。写第一版代码时很容易给什么都套一层接口，觉得扩展性好；等到接口膨胀到十几个方法、每个实现类里一半是空函数的时候，才发现当初那个 enum 加 switch 才是更合适的选择。类型集合会不会变、变化频率有多高、调用方是不是跨模块，这几个问题在动手之前想清楚，比事后重构省太多力气。至于虚表那些底层细节，平时写业务代码确实用不上，但一旦遇到"明明写了 override 却没生效""release 崩 debug 好"这类问题，脑子里有那张内存图，定位速度完全是两个量级。
