C++把多态分成了两个世界：一个在编译期完成所有决定，一个把决定推迟到运行期。前者依赖模板、重载和自动类型推导，后者依赖虚函数、继承和虚函数表。理解这两套机制的底层运作方式，才能在性能、扩展性和维护成本之间做出合理取舍。
编译时多态：模板与重载的静态分派
编译时多态的核心思想是在代码被翻译成机器码之前，就确定每个调用该绑定到哪一个具体函数实现。最常见的载体是函数重载和模板。函数重载允许同一个函数名对应多个不同参数列表的版本，编译器在调用点根据实参类型选择最合适的那个。模板则更进一步，把类型本身当作参数，让编译器为每一种实际用到的类型生成一份专用代码。
例如一个简单的加法函数，可以用模板写成下面这样，编译器会针对 int 和 double 分别实例化出两个版本。调用 add(3, 4) 时，目标地址在编译期就已经确定，生成的汇编里甚至看不到函数调用指令，因为编译器大概率会把整个加法操作直接内联到调用处。
template <typename T>
T add(T a, T b) {
return a + b;
}
int main() {
int x = add(3, 4);
double y = add(2.5, 1.5);
return 0;
}
这种机制的优点是零抽象成本。模板不会引入额外的间接调用层，也不会强制对象携带额外指针。所有类型检查在编译期完成，错误的类型组合会在编译阶段直接报错，不会留到运行时才暴露。标准库中的 std::sort 就是典型例子：传入一个 std::vector<int> 和一个 lambda 时，编译器会生成一段专门处理 int 和该 lambda 的排序代码，比较操作通常被内联，整体性能可以接近手写 C 风格代码。
但编译时多态也有明显代价。每一组不同类型参数都会生成一份新的机器码，模板使用越广泛，最终二进制文件越容易膨胀。编译时间也会大幅增加，因为编译器需要为每个实例化版本执行完整的语法和语义检查。更棘手的是错误信息：模板出错时，编译器常常会输出长达数十行的嵌套类型信息，调试体验并不友好。此外，模板无法直接放进运行时才能确定类型的异构容器中，因为模板实例化必须在编译期知道具体类型。
运行时多态：虚函数与动态绑定
运行时多态的实现基础是继承和虚函数。当一个类声明了虚函数，编译器会为这个类生成一张虚函数表，存放该类的各个虚函数入口地址。每个含有虚函数的对象内部会有一个隐藏的指针，指向自己所属类的虚函数表。通过基类指针或引用调用虚函数时，程序会先找到对象的虚表指针，再根据虚函数在表中的偏移量取出实际函数地址，然后完成调用。
下面这个经典的图形例子展示了虚函数的工作方式。基类 Shape 定义纯虚函数 area，派生类各自实现自己的面积计算。容器里保存的是基类指针，实际指向的对象既有圆也有正方形。调用 area 时，系统在运行期根据对象真实类型决定调用哪一个 area 实现。
class Shape {
public:
virtual double area() const = 0;
virtual ~Shape() {}
};
class Circle : public Shape {
double r;
public:
explicit Circle(double radius) : r(radius) {}
double area() const override { return 3.14159 * r * r; }
};
class Square : public Shape {
double s;
public:
explicit Square(double side) : s(side) {}
double area() const override { return s * s; }
};
#include <vector>
double totalArea(const std::vector<Shape*>& shapes) {
double total = 0.0;
for (Shape* s : shapes) {
total += s->area();
}
return total;
}
这种动态分派机制的最大价值在于灵活。程序在编译期不需要知道未来会出现哪些具体子类，只要它们继承自同一个基类并实现虚函数接口，就能被现有代码统一处理。插件架构就是典型场景：宿主程序定义插件接口，第三方开发者可以在不改动宿主源码的情况下添加新插件，编译后的动态库在运行时被加载并接入虚函数体系。二进制兼容性也因此成为可能，因为虚函数表的结构在 ABI 层面被固定下来。
运行时多态的代价同样清晰。每一次虚函数调用都要经过一次间接寻址，这比直接调用多出一次内存访问。更重要的是，编译器在编译期不知道调用目标，无法对虚函数调用做内联优化，哪怕函数体只有一行。虚函数的间接跳转还会干扰处理器的分支预测和指令缓存局部性，在紧密循环中频繁调用虚函数可能造成明显性能损失。另外，每个含虚函数的对象都至少要额外存储一个虚表指针，在大量小对象的场景下，内存开销比例会被放大。
性能差异的根源与测量
要理解两者的性能差异，不能只停留在“虚函数慢”这样的笼统结论上。虚函数调用的额外成本来自两层：第一层是虚表指针的解引用，第二层是被调用函数无法内联造成的优化缺失。在单次调用中，间接寻址的几纳秒开销通常可以忽略，但在每秒数百万次以上的调用频率下，缓存未命中和分支预测失败会成倍放大这项开销。
编译时多态之所以快，正是因为它消除了这两层成本。模板实例化后的函数和普通函数没有区别，调用地址可以在编译期确定，编译器能够把函数体直接嵌入调用点，进而触发更多后续优化，比如常量传播、死代码消除和指令重排。下面这个测试程序可以粗略对比两类调用的耗时差异，实际结果会受编译器优化级别、CPU 架构和缓存状态影响，但总体趋势不变：循环体内的虚函数调用通常慢于模板或直接调用。
#include <chrono>
#include <iostream>
#include <vector>
struct Base {
virtual int value() const = 0;
virtual ~Base() {}
};
struct Derived : Base {
int value() const override { return 42; }
};
template <typename T>
int callTemplate(const T& obj) {
return obj.value();
}
int main() {
std::vector<Base*> objs;
Derived d;
for (int i = 0; i < 1000; ++i) {
objs.push_back(&d);
}
auto start = std::chrono::high_resolution_clock::now();
int sum = 0;
for (auto* obj : objs) {
for (int i = 0; i < 1000; ++i) {
sum += obj->value();
}
}
auto end = std::chrono::high_resolution_clock::now();
std::cout << "virtual call: "
<< std::chrono::duration_cast<std::chrono::microseconds>(end - start).count()
<< " us\n";
start = std::chrono::high_resolution_clock::now();
int sum2 = 0;
for (int i = 0; i < 1000000; ++i) {
sum2 += callTemplate(d);
}
end = std::chrono::high_resolution_clock::now();
std::cout << "template call: "
<< std::chrono::duration_cast<std::chrono::microseconds>(end - start).count()
<< " us\n";
return sum + sum2;
}
除了调用开销，对象内存布局也直接影响性能。虚继承和多重继承会使虚表指针和对象偏移变得复杂，访问虚基类成员时可能引入额外间接层。模板则完全不会改变对象布局，每个实例化出来的类都保持普通类的内存特征。在高性能计算、游戏引擎和嵌入式系统中，这种确定性往往比灵活性更重要。
根据需求权衡：选择策略与混合方案
选择编译时多态还是运行时多态，首先要看类型集合是否在编译期可确定。如果所有可能参与运算的类型在编码阶段就能穷举，而且这些类型不会以插件形式在将来动态扩展，那么模板或 std::variant 通常是更好的选择。模板可以获得极致性能，std::variant 则以类似联合体的方式在固定类型集合上提供安全的“动态”行为，配合 std::visit 能在编译期生成所有可能的分支，避免虚函数调用。
下面这个 std::variant 版本的面积计算，表面上和虚函数容器一样可以存放不同类型的对象，但所有类型都必须在编译期声明。编译器会为每个类型生成对应的调用路径，运行时不会查虚表，而是通过索引直接跳转到正确的函数代码。这种方案适合类型集合固定、但需要在运行时切换类型的场景，比纯虚函数更快，比纯模板更易于统一存储。
#include <variant>
#include <vector>
struct Circle { double r; };
struct Square { double s; };
double area(const Circle& c) { return 3.14159 * c.r * c.r; }
double area(const Square& s) { return s.s * s.s; }
using Shape = std::variant<Circle, Square>;
double totalArea(const std::vector<Shape>& shapes) {
double total = 0.0;
for (const auto& shape : shapes) {
total += std::visit([](const auto& s) { return area(s); }, shape);
}
return total;
}
反过来，如果程序需要在不重新编译主程序的情况下添加新类型，或者需要跨动态库边界传递对象，运行时多态的虚函数体系就不可替代。框架和基础设施代码通常需要保持稳定的 ABI，让第三方能够在未来实现新的子类。此时虚函数那一点间接调用开销，相比它带来的可扩展性和解耦收益，通常可以接受。
实际项目中还有大量中间地带。例如标准库的 std::function 用类型擦除技术包装任意可调用对象，内部实现了类似虚函数的间接调用，但把模板的可调用对象类型隐藏在一个固定接口后面。这种做法牺牲了一部分内联机会，换来了统一的存储和传递能力。另一个常见策略是热路径使用模板，冷路径使用虚函数：在性能敏感的核心算法中尽量采用编译时多态消除调用开销，在模块边界和扩展点上保留虚函数接口，兼顾性能和灵活性。最终决策应当基于测量数据，而不是单纯依靠“模板快、虚函数慢”的经验直觉。