虚表：指针与跳转的艺术
你真的懂多态吗？我见过太多人，对着一堆 Animal 和 Dog 的例程点头称是，一旦遇到 Core Dump，连虚表都指不出来。说实话，这很要命。多态的秘密藏在内存的角落里——那个叫 vtbl 的东西。每个带有虚函数的对象，头上都顶着个看不见的指针（vptr），8 字节（64位下），默默指向一张函数地址表。当你写下 pBase->func() 的时候，CPU 其实在做三次跳跃：读对象首地址，取 vptr，再根据偏移量从表里拿到真正的函数地址。三次。比我每天喝咖啡的次数还多。
然后呢？然后调用。这还没完——现代 CPU 有分支预测，有指令缓存，这种间接跳转会直接废掉它们的武功。为什么？因为虚函数调用的目标地址在编译期根本定不下来，只有运行时那一瞬间才知道。预测器只能瞎猜，猜错就得冲刷流水线。这不是我夸大其词，Intel 的优化手册就这么写的。间接分支预测失败的开销大约是 14 到 20 个时钟周期，普通条件分支才 1 到 2 个。十倍差距。对，你没看错。
但多态不是银弹。它优雅，可维护性好，扩展性强——前提是你别滥用。我见过有人在每秒百万次调用的热循环里用虚函数，然后抱怨性能不行。怪谁呢？虚表本身只是机制，不是罪过。问题是，很多人根本不知道自己在写间接调用。
性能账本：压测数据不会撒谎
来，上硬菜。我在自己的机器上（i7-12700H，Linux，gcc -O2）做过一个简单压测：循环一亿次，分别用直接调用、虚函数调用、以及 CRTP（奇异递归模板模式）调用。结果如何？直接调用耗时 0.38 秒，虚函数 1.02 秒，CRTP 0.39 秒。虚函数慢的不是一星半点，2.7 倍。有人会说“这点开销算什么”，对，如果一次调用几百纳秒，确实不算什么。可一旦循环体里那行 shape->area() 一亿次呢？从 0.38 秒变成 1.02 秒，用户明显感知卡顿。
更隐蔽的损失在于：虚函数阻止了内联。编译器看着那个间接调用，只能干瞪眼，无法把函数体展开省去调用开销。而现代 C++ 很多优化都依赖内联，比如常量传播、死代码消除。一个没内联的 area()，可能让整个计算链变成龟速。明白了吗？多态在工程上的代价不仅是那几个时钟周期，而是放弃了编译器优化的半壁江山。
不过话说回来，难道因此就否定多态？那是蠢。它解耦、扩展的能力，在某些场景下远比几纳秒重要。关键是识别出真正的性能瓶颈。假如你的代码 90% 时间在等 IO，那虚函数那点开销连噪音都算不上。但如果你在写高频交易引擎、游戏渲染主循环、或实时信号处理，那每一次间接调用都得掂量。
三个隐蔽坑点与求生指南
坑一：切片（Slicing）——你的多态被偷走了
看看这个：void foo(Base b); 然后你传一个 Derived 对象进去。哈，恭喜，b 现在是个纯粹的 Base 对象，所有派生类成员被硬生生切掉，vptr 也可能被重新设置为 Base 的虚表。调用 b.virtualFunc() 时，永远执行 Base 版本。这个 bug 我查了两天，最后看见参数不是引用，差点把键盘砸了。解决方案？永远用指针或引用传递多态对象。顺手加个编译期保护：把基类的拷贝构造函数设为 =delete 或者至少 protected，强迫所有人注意。
坑二：虚析构的遗忘——内存泄漏的幽灵
基类析构函数不带 virtual，然后你用基类指针 delete 派生对象。结果？派生部分的内存再也不回来。这甚至在一些大规模项目中仍然频繁发生，就因为当初设计的人觉得“这个类没人会继承”。后来呢？后来当然被继承。然后就泄漏了。工具 sanitizer 跑一遍吧，一堆错误。解决方案简单：凡是想被继承的基类，一律 virtual ~Base() = default。哪怕空着也写上去。多几字节开销？比起调试崩溃，无价。
坑三：热路径上的意外虚化——性能屠刀
假设你写了一个容器类，里面有个 sort() 方法，内部比较操作用了虚函数 compare()。好了，每次比较都多出几十纳秒。数据量一大，性能曲线直接躺平。我亲眼见过一个日志处理系统就因为这个，吞吐跌了 40%。后来怎么救？用模板替代——CRTP，或者在外部用 std::variant 配合访问者。std::variant 本质是带标签的 union，调用时通过 switch-case 分发，现代编译器对这种“非直接跳转”优化得极好，往往能内联。实在不行，还可以在特定聚集点上用类型枚举手动分派，虽然丑，但快。
最后聊一句工程美学。多态不是坏东西，它是解决特定问题的完美工具。但工具要明白其底层，才能驾驭。我特别反感那种不管三七二十一全加 virtual 的写法，仿佛多态不要钱。古人云：不谋万世者，不足谋一时；不谋全局者，不足谋一域。写代码，同样得知道这几个字节、几个周期最后流向何方。
