C++静态多态实战：从虚函数到CRTP与std::variant

最近一次代码评审，同事指着我写的一个基类接口直接问："这六个虚函数，真的都需要吗？"我愣了一下。确实，如果只是为了在容器里塞进不同类型对象，然后统一调用它们各自的行为，C++里真不只有虚函数这一条路。还有一套完全在编译期完成分发的机制——也就是大家常说的静态多态。

静态多态不是什么冷门黑魔法，恰恰相反，日常写模板、重载函数、用CRTP提升基类代码复用，本质上都在吃这碗饭。它最大的特点就一句话：决策发生在编译期，运行时不需要任何间接跳转，也不依赖虚表。代价则是代码形态更"拧巴"，对设计者的要求更高。

这篇文章我想从一次真实的性能排查出发，把静态多态家族的几种实现方式、它们和虚函数的成本差异、以及我在工程里踩过的坑完整掰开讲一遍。适合已经写过一阵C++、想摆脱"只会继承+虚函数"这种思维定式的开发者，也适合准备面试时被问"静态多态和动态多态区别"的同学。内容里给出的代码全部基于C++17/20，编译器用的是GCC 12和Clang 16，两者行为一致。

1. 编译期决议：静态多态的四种形态与共同本质

1.1 四种最常见的实现形态

静态多态听起来像个高深术语，其实它是由好几类不同的语言机制拼在一起的，它们共享一个特征：调用目标在编译期就能确定。

第一类是函数重载。同一个函数名、不同的参数类型列表，编译器根据实参静态选择最佳匹配。这不只是语法糖，它实际上就是最基础的编译期分发。当你写 std::to_string(42) 和 std::to_string(3.14) 时，编译器已经帮你选好了不同的函数入口。

第二类是模板。函数模板和类模板在实例化时按类型生成对应代码，换句话说，类型本身就是那个"分发条件"。传入 std::vector<int> 和 std::vector<std::string>，生成的是两份完全不同的代码。这背后是模板的鸭子类型特性：只要类型提供所需操作，就能参与运算，不要求继承关系。

第三类是CRTP（Curiously Recurring Template Pattern），中文叫奇异递归模板模式。它用 template <typename Derived> class Base 这种写法，让基类反过来知道派生类的具体类型，从而在基类中调用 static_cast<Derived*>(this) 来执行派生类方法。这套东西在编译期就把"谁是子类"这个信息绑定死了，运行时零开销。

第四类是 std::variant 配合 std::visit。这个组合把一个有限类型集合（如 variant<Circle, Rectangle>）塞进类型系统，访问时通过 <variant> 内部的编译期生成逻辑分发。它既不是继承关系，也没有虚表，但同样实现了"这堆对象统一处理"的效果。

1.2 共同逻辑：把一切选择留给编译器

四类形态看起来五花八门，内在逻辑是一致的：调用方在编译期就能知道被调方的完整信息，于是不需要间接寻址。

动态多态（虚函数）的思路是"我不知道具体是谁，但我知道它一定实现了这个接口，运行时查一下虚表"。静态多态的思路是"我知道它具体是谁，所以我可以直接生成对齐的代码"。你可以把动态多态理解成外卖平台上的商家页——你看不到厨房，只能通过平台统一接口下单；静态多态则是你直接走到后厨，看着厨师做菜，自然不需要对讲机。

这种差异带来的直接后果是：

• 静态多态支持零成本抽象。所有调用都能被内联，编译器可以做跨调用边界的优化。
• 静态多态的类型关系靠的是"结构契约"而非"继承契约"。只要类型上有对应方法，就能传入模板。
• 静态多态的代价是代码量上升。每实例化一组类型，编译器就生成一份对应代码，二进制体积和编译时间都会涨。

记住这个本质，后面所有技术细节都不会跑偏。

2. 虚函数与模板的账本对比：从vtable开销到代码膨胀

2.1 虚函数调用到底贵在哪

很多人觉得虚函数开销可以忽略，这个观点在小规模调用下确实成立，但在热路径上问题会被放大。虚函数调用至少有三笔账要付：

第一笔是间接跳转。调用 shape->area() 时，CPU要先把对象的vptr取出来，再从中取出area的函数指针，再做一次间接跳转。现代CPU的分支预测对这种间接跳转的预测成功率依赖"同一调用点是否总遇到同一目标代码"。如果你一个循环里交替访问Circle和Rectangle，这个预测基本失效，流水线会频繁清空。

第二笔是内联失效。虚函数调用无法跨调用边界内联（除非编译器做了devirtualization优化），这意味着每次调用都要走完整函数进出流程，小函数的性能损失尤其明显。比如一个只读一个成员变量的getter，一旦变成虚函数，它就从"一条指令"膨胀成"一次调用"。

第三笔是缓存友好性。虚表本身不在对象里，虚函数代码往往是独立的冷块，调用时可能发生指令缓存不命中。在嵌入式设备、高频交易引擎、游戏引擎的紧密循环里，这三点可以累积成5%~15%的额外开销。我之前优化过一个事件分发模块，单纯把虚函数分发换成编译期分发，吞吐量就上去了约8%，后面第6章会详细给数据。

2.2 模板、CRTP和variant的账本

静态多态不能只谈收益，它的成本同样现实。

模板核心问题是代码膨胀。process<int>和process<double>各生成一份完整代码。如果模板内部又实例化了其他模板，那就是爆炸式组合。我在大型项目里见过一次因为滥用高级模板导致单文件编译CPU时间从20秒涨到3分钟的情况。控制手段有几种：把模板中稳定的大段逻辑抽成非模板函数，让模板只处理类型差异那一小部分；或者使用extern template显式实例化声明，把实例化集中到固定编译单元。

CRTP则有一个隐蔽的维护成本：类型关系是隐式的。ShapeBase<Circle>和Circle之间没有is-a关系，代码里看不出来，只有阅读模板定义才能理解"这个基类要求你实现areaImpl"。团队协作时如果不写清楚文档，新人很容易看不懂为什么会写static_cast<const Derived*>(this)。

std::variant这类方案的代价是固定类型集合。它要求所有可能的类型在编译期就枚举出来，一旦要增加新类型，需要改动多处（声明、visitor、构造函数）。而虚函数天然支持跨编译单元扩展——库作者不知道使用方会继承出什么新类，这是它至今不可替代的重要原因。

2.3 我自己的选择判据

结合上面说的成本和收益，我在实际工程里基本按下面这张表决策：

这个表不是教条，但它帮我在很多次方案讨论里省去了来回拉扯。核心思路是：**先问类型集合是否开放，再问