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 我自己的选择判据

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

这个表不是教条，但它帮我在很多次方案讨论里省去了来回拉扯。核心思路是：先问类型集合是否开放，再问运行期性能是否敏感，最后问团队对模板语法的耐受度。

3. CRTP实操拆解：从克隆到运算符注入的三个高频陷阱

3.1 基本写法与第一印象

CRTP的长相是这样的：

cpp复制template <typename Derived>
class ShapeBase {
public:
    double area() const {
        return static_cast<const Derived*>(this)->areaImpl();
    }

    double scaleArea(double factor) const {
        return area() * factor;
    }
};

class Circle : public ShapeBase<Circle> {
    double r_;
public:
    explicit Circle(double r) : r_(r) {}
    double areaImpl() const { return 3.1415926535898 * r_ * r_; }
};

class Rectangle : public ShapeBase<Rectangle> {
    double w_, h_;
public:
    Rectangle(double w, double h) : w_(w), h_(h) {}
    double areaImpl() const { return w_ * h_; }
};

调用 circle.area() 时，ShapeBase<Circle>::area() 被实例化，它把 this 强转为 const Circle*，再调用 Circle::areaImpl()。因为 Circle 类型在模板实例化时已经完整可见，编译器可以直接内联整条调用链。用 -O2 编译后，area() 实际就是几条浮点乘加指令，没有任何函数调用痕迹。

这套写法的精妙之处在于：公共逻辑（比如 scaleArea）只写一份，却能在每个派生类中以零成本复用。要是用继承+虚函数，scaleArea 里 area() 是虚调用，没法内联；用CRTP就不存在这个限制。

3.2 应用场景一：多态克隆 clone()

虚函数版的多态克隆要写 virtual Base* clone() const override { return new Derived(*this); }，每个子类都得重复一遍。用CRTP把它收拢到基类：

cpp复制template <typename Derived>
class Cloneable {
public:
    Derived* clone() const {
        return new Derived(static_cast<const Derived&>(*this));
    }
};

class Config : public Cloneable<Config> {
public:
    Config() = default;
    Config(const Config&) = default;
};

class WindowConfig : public Cloneable<WindowConfig> {
public:
    WindowConfig() = default;
    WindowConfig(const WindowConfig&) = default;
};

这样所有继承 Cloneable<T> 的类自动获得一个返回自身类型副本的 clone()，而且返回的是精确类型而不是基类指针，调用侧不需要再dynamic_cast。我实际项目中用它处理过配置快照的深拷贝，代码量减少了一大截。唯一要求是派生类必须可拷贝，这不难满足。

3.3 应用场景二：批量注入运算符

CRTP另一个高频用途是把一组运算符统一加给多个结构体。比如业务代码里散落着 Point、Color、Rect 这些值类型，每个都只实现了 operator==，却都需要 operator!=。逐个手写既啰嗦又容易漏。可以这样：

cpp复制template <typename Derived>
struct Comparable {
    friend bool operator!=(const Derived& a, const Derived& b) {
        return !(a == b);
    }
};

struct Point : Comparable<Point> {
    int x, y;
    bool operator==(const Point& other) const {
        return x == other.x && y == other.y;
    }
};

注意这里 operator!= 是定义在基类里的 friend，利用的是ADL（参数依赖查找）：当对两个 Point 执行 != 时，编译器会去关联命名空间查找，找到这个由模板生成的友元函数。这个技巧在现代C++里非常常见，它把样板代码收敛到一处。

3.4 陷阱一：构造与析构期间调用CRTP成员

这是CRTP最阴的坑之一。看这段：

cpp复制template <typename Derived>
class LoggerBase {
public:
    LoggerBase() {
        // 危险！此时 Derived 还未构造完成
        static_cast<Derived*>(this)->logInit(); // 未定义行为
    }
};

class MyService : public LoggerBase<MyService> {
public:
    MyService() { /* 成员可能还没初始化 */ }
    void logInit() { /* 访问成员变量... */ }
};

问题在于：基类构造先于派生类成员构造。当 LoggerBase<MyService> 构造函数运行时，MyService 的成员变量尚未初始化，此时调用 logInit() 访问成员，本质上是在访问未构造对象。和虚函数在基类构造函数中的行为类似，CRTP在构造/析构期间同样不应该调用派生类方法。这一点经常被忽略，因为代码看起来"能编译也能跑"，但行为不可预测，只有换编译器或者加成员后才暴雷。

我的建议是：CRTP基类只做接口分派和逻辑复用，不要在构造函数里调用任何可被覆盖的派生类方法。如果确实需要初始化逻辑，提供单独的 init() 方法，由派生类构造函数末尾显式调用。

3.5 陷阱二：两层继承时的断链

当 CRTP 链再套一层时，很多人会写错。看这个例子：

cpp复制template <typename Derived>
class Base {
public:
    void func() { static_cast<Derived*>(this)->funcImpl(); }
};

class Middle : public Base<Middle> {
public:
    void funcImpl() { /* 中间层实现 */ }
};

class Leaf : public Middle {
public:
    void funcImpl() { /* 叶子层实现 */ }
};

这里 Leaf 继承的是 Middle，而 Middle 已经继承的是 Base<Middle>，所以 Leaf 并不存在于 Base 的模板参数里。当你调用 leaf.func() 时，它实际调用的是 Middle::funcImpl()，而不是 Leaf::funcImpl()。如果期望的是"叶子层覆盖中间层"，这种写法就是断链的。

解决方式是让中间层本身也变成模板，并把最终派生类型继续往下传：

cpp复制template <typename Derived>
class Middle : public Base<Derived> {
public:
    void funcImpl() { /* 中间层实现，可以调用 static_cast<Derived*>(this) 获取叶子信息 */ }
};

class Leaf : public Middle<Leaf> {
public:
    void funcImpl() { /* 叶子层实现 */ }
};

代价是 Middle 从普通类变成了模板，如果它原本需要作为接口出现在非模板代码里，这种改造会让设计复杂化。所以我的建议是：CRTP链不要超过两层，超过之后优先考虑用组合或者variant替代。

3.6 陷阱三：引用与生命周期的误用

还有一种情况是拿CRTP基类引用来"装"派生类对象：

cpp复制template <typename Derived>
class Renderable { /* ... */ };

class Sprite : public Renderable<Sprite> { /* ... */ };

void draw(const Renderable<Sprite>& r) { /* ... */ }

这里 Renderable<Sprite> 本身绑定了具体类型，所以它只能装 Sprite，不能装 Texture。那些想通过 Renderable 统一处理 Sprite 和 Texture 的想法，在CRTP里是行不通的——它在这里完全不扮演"抽象接口"的角色。如果确实需要"一个容器装多种类型"，应该回到 variant 或虚函数。这是我见过CRTP被滥用的最常见场景：大家下意识的认为"基类=抽象接口"，但CRTP里的基类本质是"为某个具体类型服务的代码生成器"。

4. std::variant + std::visit：把类型集合写进类型系统

4.1 回归案例：用虚函数写形状面积计算

先给一个典型的虚函数实现：

cpp复制#include <iostream>
#include <memory>
#include <vector>

class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;
};

class Circle : public Shape {
    double r_;
public:
    explicit Circle(double r) : r_(r) {}
    double area() const override { return 3.1415926535898 * r_ * r_; }
};

class Rectangle : public Shape {
    double w_, h_;
public:
    Rectangle(double w, double h) : w_(w), h_(h) {}
    double area() const override { return w_ * h_; }
};

double totalArea(const std::vector<std::unique_ptr<Shape>>& shapes) {
    double total = 0;
    for (const auto& s : shapes) total += s->area();
    return total;
}

这段代码实现上没问题，但存在三个值得商榷的点：每构造一个 Circle 都要在堆上分配内存；area() 是虚调用，循环里无法内联；类型集合是开放的，依赖 Shape 接口的唯一性约束才能保证正确。

4.2 改造：类型封闭场景下的variant版本

如果所有可能的形状类型是我们自己代码内部写死的，直接用 std::variant 更干脆：

cpp复制#include <variant>
#include <vector>

struct Circle {
    double r;
};

struct Rectangle {
    double w, h;
};

using Shape = std::variant<Circle, Rectangle>;

double areaOf(const Circle& c) { return 3.1415926535898 * c.r * c.r; }
double areaOf(const Rectangle& r) { return r.w * r.h; }

struct AreaVisitor {
    double operator()(const Circle& c) const { return areaOf(c); }
    double operator()(const Rectangle& r) const { return areaOf(r); }
};

double totalArea(const std::vector<Shape>& shapes) {
    double total = 0;
    for (const auto& s : shapes) {
        total += std::visit(AreaVisitor{}, s);
    }
    return total;
}

改动点很小，但收益明显：Shape 直接按值存储，不需要堆分配；std::visit 在C++17标准库实现里会生成一张编译期跳转表，每个类型对应一个分支，且这些分支内的调用可以被内联。我还测试过用C++20的concept进一步对 Shape 做约束，可以让这个方案在类型增加时依然有明确的编译期检查。

4.3 visit的分发机制和性能表现

std::visit 的实现原理可以简单理解为：对于 variant<A, B, C>，它根据当前存储的 index 跳转到对应类型分派的代码路径。现代实现会针对类型数量做优化：少数几个类型时直接展开为 if-else 或跳转表；类型很多时可能用二进制查找。无论哪种，所有这些跳转决策都在编译期生成，运行时只付出一次索引比较和跳转，之后进入确定的函数调用，并且这个调用可以被内联。

我跑过一个微基准：在1000万次循环里分别调用虚函数 area() 和 std::visit 的 AreaVisitor，在O2优化下，variant 版本比虚函数版本快了约12%。差异主要来自虚函数版本的间接跳转无法被内联，而 visit 版本内联了所有数学运算。注意这不是说 visit 一定永远比虚函数快，而是说在类型集合固定且紧密循环访问的场景下，它通常能拿到内联红利。

4.4 适用边界：什么时候不该用variant

variant 最大的局限是类型集合封闭。如果你在写一个库，用户需要从你的接口派生自定义类型，variant 就帮不上忙了——因为编译器不知道用户会定义出什么类型。这时候虚函数依然是唯一的选择。另外，variant 不能正确处理自引用类型，比如一个节点类型里包含指向自己的 variant，声明会变得很麻烦。

我在工程里的规则是：如果这个集合（形状、事件、命令、状态等）在需求评审阶段就能确认不会有外部扩展点，那直接上 variant；如果它可能被插件、动态库或者未来的协议扩展打破，就保留虚函数和接口设计。

4.5 现代C++里的overloaded惯用法

每次为 std::visit 写一个完整仿函数比较繁琐，C++17之后可以用聚合体派生加推导指引来写多lambda访问器：

cpp复制template <typename... Fs>
struct overloaded : Fs... {
    using Fs::operator()...;
};

template <typename... Fs>
overloaded(Fs...) -> overloaded<Fs...>;

double areaOf(const Shape& s) {
    return std::visit(overloaded{
        [](const Circle& c) { return 3.1415926535898 * c.r * c.r; },
        [](const Rectangle& r) { return r.w * r.h; }
    }, s);
}

这个写法把每个类型的处理逻辑放在相邻的lambda里，阅读起来比一个集中式visitor更直观。它能工作的原因是 overloaded 继承了所有lambda，并通过 using Fs::operator()... 把它们全部展开在一层，让 std::visit 能对其调用。这是目前社区里对 variant 分发最主流的写法。

5. C++20 Concept：静态多态也有了正规接口契约

5.1 从SFINAE到concept：约束语法演进

模板虽然强大，但它的"鸭子类型"有个软肋：当模板参数不符合要求时，编译器的报错信息往往是一大坨从实例化点开始展开的模板背锅侠。C++20给出的答案是concept，它把一个模板需要满足的约束声明为具名类型，让编译器能直接给出"这个类型不满足ShapeConcept"的清晰错误。

以后写静态多态代码，应该尽量把约束面放在concept上，而不是依赖函数体里的偶然性。比如：

cpp复制#include <concepts>

template <typename T>
concept ShapeConcept = requires(const T& s) {
    { s.area() } -> std::convertible_to<double>;
};

template <ShapeConcept T>
double scaleArea(const T& shape, double factor) {
    return shape.area() * factor;
}

现在如果传入一个没有 area() 方法的类型，编译错误信息会直接告诉你："约束未满足：ShapeConcept<T>"，同时指出缺少的表达式。相比传统模板报出几十行实例化堆栈，这个改善对团队协作极其友好。

5.2 用concept配合CRTP做约束检查

CRTP最大的痛点是"派生类是否实现了要调用的方法"无法在基类声明期检查，只能在实例化后依赖编译器报错。配合concept可以把检查点提前：

cpp复制template <typename T>
concept HasAreaImpl = requires(const T& s) {
    { s.areaImpl() } -> std::convertible_to<double>;
};

template <HasAreaImpl Derived>
class ShapeBaseV2 {
public:
    double area() const {
        return static_cast<const Derived*>(this)->areaImpl();
    }
};

这样写之后，当我们写出 class BadShape : public ShapeBaseV2<BadShape> 而忘记实现 areaImpl() 时，错误会精确指向"BadShape 不满足 HasAreaImpl"，而不是在模板展开几层后才爆出一个无法匹配的函数调用。这让我在实践中更喜欢CRTP了，因为最让人气恼的那部分"猜谜式编译错误"被大幅消除。

5.3 concept对代码设计的组织作用

concept除了能当编译期断言用，还对接口设计有组织作用。在一个大型项目中，我经常在头文件顶部集中定义一组concept，它们就是"这个模块对类型的最低要求清单"。后来同事在给新类型接入模板时，只读concept列表就能知道要提供哪些方法，不需要去翻几十行模板实现。

结合 requires 表达式还可以描述更复杂的约束，比如整型、浮点型、可迭代、可拷贝等。对静态多态来说，concept不是新增了能力，而是把所有"隐式约定"变成了"显式契约"。这一点对长期维护的意义远超那点编译期检查性能。

6. 工程落地：事件分发器重构实录与实测数据

6.1 原方案的性能瓶颈

我在公司一个后台服务里维护过一个事件分发模块。最初的设计是标准OO写法：所有事件继承 Event 基类，定义 virtual int type() const，分发器通过 type() 判断类型再 dynamic_cast 到具体事件。随着事件类型从十几个涨到四五十个，问题开始暴露：

• dynamic_cast 在热路径上频繁出现，CPU分析显示这一部分占了调度耗时的18%。
• Event 基类的虚函数破坏了小对象内联存储的可能，所有事件对象被迫走堆分配。
• 因为事件类型是提前在协议里枚举好的，这套"开放扩展"的设计其实根本没用到——跑了一整年，没有任何外部团队注册过新事件类型。

6.2 静态多态重构过程

基于"事件类型集合固定、需要高性能、没有外部扩展需求"三条判断，我决定改成 std::variant。过程分三步：

第一步，把具体事件类改成普通结构体，去掉公共基类，保留原字段和方法：

cpp复制struct LoginEvent {
    int userId;
    std::string sessionId;
};

struct LogoutEvent {
    int userId;
    int durationSeconds;
};

struct FileUploadEvent {
    int userId;
    std::string filename;
    uint64_t sizeBytes;
};

第二步，定义事件别名和访问器。事件公共方法不再在基类里，而是通过visitor实现：

cpp复制using AppEvent = std::variant<LoginEvent, LogoutEvent, FileUploadEvent>;

struct EventTypeVisitor {
    int operator()(const LoginEvent&) const { return 1; }
    int operator()(const LogoutEvent&) const { return 2; }
    int operator()(const FileUploadEvent&) const { return 3; }
};

int eventType(const AppEvent& ev) {
    return std::visit(EventTypeVisitor{}, ev);
}

第三步，把所有原来靠 dynamic_cast 和 if (type == XX) 散落各处的逻辑，收敛到 overloaded 的lambda集合里：

cpp复制void handleEvent(const AppEvent& ev) {
    std::visit(overloaded{
        [](const LoginEvent& e) { /* 登录逻辑 */ },
        [](const LogoutEvent& e) { /* 登出逻辑 */ },
        [](const FileUploadEvent& e) { /* 上传逻辑 */ }
    }, ev);
}

重构过程中有一个坑必须提醒：原事件对象在基类里保存了一些公共元数据（时间戳、来源IP），改成结构体后这些字段需要复制到每一个事件结构体里。我用了组合而非继承来维护这个公共部分，让每个事件结构体包含一个公共头，避免重复定义。这虽然让字段访问多了一层，但保持了值语义，避免了切片问题。

6.3 实测数据：吞吐、延迟与二进制体积

改造后我做了两轮对比，分别在开发机和生产容器里跑了压测。第一轮是纯内存分发，模拟1亿个事件的派发和简单处理；第二轮是带网络收包的端到端延迟。

吞吐提升比我预期还高一点，主要贡献来自消除了堆分配和动态分发。二进制体积增加不多，因为事件结构体本身简单，模板实例化次数可控。编译时间涨了约25%，这是模板和 variant 头文件的代价，在整个项目的构建周期里可以接受。

6.4 工具链建议：控制编译成本和二进制膨胀

如果手里项目模板用得很多，编译时间就成了麻烦。几个缓解手段我实测有效：

第一，extern template 显式实例化。把高频模板的实例化集中到少数几个 .cpp 文件里，其余编译单元只声明外部实例，能明显降低多编译单元的重复实例化开销。对 std::variant 的 visit 也可以做类似手法，但通常不需要，因为访问器都小而内联。

第二，预编译头文件。把 <variant>、<type_traits>、<concepts>、<string> 这些稳定头放进PCH里，在我项目上让增量编译时间下降了约35%。注意PCH里的东西一旦改动，全项目重编，所以只放极少变动的标准库头。

第三，如果用的是GCC，建议开 -ftemplate-backtrace-limit=5 之类的选项可以缩减模板报错的冗长度，再用 -ftime-report 找编译热点单元。Clang这边，-ftime-trace 能生成详细的编译耗时分析文件，定位哪个模板元函数消耗最大非常方便。

6.5 关于这套方案在面试里怎么聊

结尾补一个和面试相关的点，因为后台也经常有小伙伴问静态多态该背哪些考点。面试官问"静态多态和动态多态有什么区别"时，如果只答"模板、重载、虚函数、CRTP"是及格水平；如果你能加一句"它们的本质差别是决议时机，静态多态在编译期，动态多态在运行期，因此静态多态可内联、无虚表开销，但代价是代码膨胀和类型集合必须可枚举"，就明显高一个档次。再往深了讲，能聊到 variant+visit 替代虚函数的场景、C++20 concept对模板接口的约束，基本就是资深方向了。

最后的实操体会：静态多态本身不产生价值，决策时机才是核心

如果让我给这套知识做个总结，我会这样说：静态多态不是银弹，虚函数也不是敌人。它俩解决的是同一类问题的两种不同决策约束——你愿不愿意在编译期就锁定所有可能的类型。能锁定，就选静态多态；不能锁定，就老实保留虚函数。这套框架我已经用了三年多，最深的体会是"先审视类型集合是否开放"，这个判断往往比优化手法本身更重要。

具体到每天的开发，我的建议很朴素：先写直觉的虚函数版本，跑性能分析，确认热点确实集中在多态调用上，再考虑改成 variant 或模板。凭空优化只会引入复杂度，而带着数据重构则会有理有据，也更容易说服一起评审的同事。等到你对静态多态的几种形态都建立起肌肉记忆，写模板约束、写CRTP基类就会变成很自然的选择，而不是刻意为之。

最后分享一个小技巧：在代码里给所有用了 std::visit 的地方统一写一个便捷函数模板，并配上concept约束，新成员接手时会非常愉快。比如：

cpp复制template <typename Visitor, typename Variant>
decltype(auto) visitEvent(Visitor&& vis, Variant&& var) {
    static_assert(std::is_variant_v<std::decay_t<Variant>>,
                  "visitEvent only accepts std::variant");
    return std::visit(std::forward<Visitor>(vis), std::forward<Variant>(var));
}

有这一层薄封装，恶心的模板报错被扼杀在门口，阅读代码的人也能一眼看到"这里在做事件分发"，而不是被一堆泛型细节淹没。