C++多态底层原理：从虚函数表到vptr的完整体系

在C++的一众知识点里，多态属于那种“手写起来很简单，往深一问就卡壳”的东西。面试官一句“虚函数底层是怎么实现的”能劝退不少背过八股文的候选人。我早期写业务代码时对多态的理解也停留在“加个virtual关键字的类，然后就能统一调用了”，直到后来做性能剖析、研究对象内存布局时，才算把这块彻底串通。这篇想用实践视角把C++多态拆开讲：既有概念、也有实现原理，最后落到面试题和真实编码取舍上。适合所有正在学C++、准备面试，或者写了好几年代码但对多态仍处于“会背不会讲”状态的开发者。

1. 先搞明白“多态”到底解决什么问题

1.1 一个没有多态的世界：switch-case 地狱

很多教材一上来就讲虚函数、虚表，说实话容易把初学者劝退。我更喜欢从一个反面案例开始——先看看没有多态的时代，代码是怎么写下去的。

假设你在做一个游戏里的角色伤害系统，有普通怪、Boss、机械守卫三种敌人，每个受击后的表现不一样。如果没有多态，最常见的写法是给每种怪物打一个类型编号，然后在受击函数里写一堆分支：

cpp复制struct Monster {
    int type;  // 0=普通怪，1=Boss，2=机械守卫
};

void injure(Monster& m, int damage) {
    if (m.type == 0) {
        // 普通怪：正常掉血、播放基本音效
    } else if (m.type == 1) {
        // Boss：减伤、播放Boss音效、触发震屏
    } else if (m.type == 2) {
        // 机械守卫：掉血但无音效、播放金属碰撞特效
    }
    // 每次新增怪物类型，都要来这里加分支
}

这种代码最大的问题不是“不够面向对象”，而是每一次新增怪物类型，都要去修改同一个函数。项目小的时候还好，等业务逻辑跑到几百行、多个模块共享这同一个分支时，改一处就可能炸掉一片。而且分支判断会不断膨胀，最后变成几百行的“意大利面”。

多态的价值就在这里：它把“调用方”和“具体实现”解耦。调用方只依赖一个抽象接口——比如“这个怪物可以被伤害”——至于它是普通怪还是Boss，具体怎么掉血、播什么特效，由各自的实现类自己负责。

cpp复制class Monster {
public:
    virtual void injure(int damage) = 0;
    virtual ~Monster() = default;
};

class NormalMonster : public Monster {
    void injure(int damage) override { /* 普通掉血逻辑 */ }
};

class BossMonster : public Monster {
    void injure(int damage) override { /* 减伤、震屏逻辑 */ }
};

新增一种怪物，只需要新增一个类，不需要动已有的调用代码。这就是多态最核心的价值，也是面试里常说的“开闭原则”：对扩展开放、对修改关闭。

1.2 静态多态与动态多态：两条路线，两个时代

严格来说，C++里的多态分两类，面试时如果只说“虚函数”其实是不完整的。

第一类是编译期多态（静态多态），最典型的是函数重载和模板。函数重载是同一个函数名，参数类型或数量不同，编译器在编译期就决定调用哪一个；模板则是编译器根据传入类型生成一份全新的代码，比如 std::sort 对不同容器类型的不同实例化。这类多态的绑定发生在编译期，运行时不额外承担任何查找开销。

第二类是运行期多态（动态多态），核心机制就是虚函数。程序运行到调用点时，编译器不知道对象的真实类型，需要先访问对象内部持有的虚函数表指针，再通过虚函数表找到真正的函数地址，然后间接调用。这也是“底层原理”真正要讲的重点。

我做个表格把两者的区别列出来，面试时直接背这个就够了：

这篇文章接下来的重点放在运行期多态上，因为“底层原理”这个词，指向的几乎就是虚函数表那一整套机制。模板那套实例化故事是另一个庞大的话题，以后可以单独开一篇讲。

2. 虚函数与虚表：动态多态的底层支柱

2.1 vtable 是什么：一张由函数指针构成的表格

先从一个最小例子说起：

cpp复制class Animal {
public:
    virtual void speak() { std::cout << "Animal::speak" << std::endl; }
    virtual void move()  { std::cout << "Animal::move" << std::endl; }
    virtual ~Animal() {}
    int age_ = 0;
};

编译器在处理这个类时，会发生一件肉眼看不到的事：自动生成一张虚函数表。这张表本质上是一个数组，里面存放的是类的虚函数的地址。对上面的 Animal 来说，它的 vtable 大致长这样：

code复制Animal 的 vtable:
槽位 1: Animal::speak 的地址
槽位 2: Animal::move  的地址
槽位 3: Animal::~Animal 的地址（析构函数实际可能占多个槽位，这是 ABI 层面的细节）

注意，这里有一个非常容易被误解的点：vtable 是类级别的，全类共享一份；vptr 是对象级别的，每个对象一个。也就是说，你创建一百个 Animal 对象，它们全都指向同一张 vtable，而不是每个对象都复制一张表。

还需要强调一句：vtable 的布局并不是 C++ 标准规定的，而是主流编译器（GCC、Clang、MSVC）按照各平台的 ABI 约定实现的。所以理论上不同编译器生成的布局可能有差异，但绝大多数场景下你看到的就是“存在一张函数指针数组”这种形式。

2.2 vptr 藏在对象内存的哪里

对象内部没有直接保存虚表，它保存的是一个指向虚表的指针，叫虚指针（vptr）。常见编译器的做法是把 vptr 放在对象的最前面。也就是说，上面 Animal 对象的内存布局看起来是这样：

text复制| vptr (8字节) | age_ (4字节) | padding (4字节) |

正因为多了这个 vptr，一个原本只存一个 int 的类，在 64 位系统下从 4 字节变成了 16 字节。很多人第一次遇到这个问题是在面试题里：“有虚函数的类对象大小怎么算？”答案就是：所有数据成员的大小 + 可能有内存对齐 padding + 一个 vptr。

我建议你自己写段代码验证一下：

cpp复制#include <iostream>

class A { };
class B {
public:
    int x;
};
class C {
public:
    virtual void f() {}
    int x;
};

int main() {
    std::cout << sizeof(A) << std::endl; // 1
    std::cout << sizeof(B) << std::endl; // 4
    std::cout << sizeof(C) << std::endl; // 16（64位环境）
}

在常见 64 位平台上，sizeof(A) 是 1，sizeof(B) 是 4，sizeof(C) 是 16。为什么空类不是 0？为了让每个对象都有唯一地址，编译器给了它 1 字节。为什么 C 是 16 而不是 12？因为 vptr 占了 8 字节，int 占 4 字节，然后为了对齐整体到 8 字节的整数倍，又补了 4 字节 padding。

搞懂这个内存布局，对后面理解覆盖、切片、多继承都有帮助。

2.3 构造函数和析构函数里的“假多态”

这部分是面试高频中的高频。先说结论：在构造函数和析构函数内部调用虚函数，不会触发动态绑定。也就是说，即使你通过派生类构造去调用，也只会调用当前正在构造/析构的这个基类版本，而不是派生类的重写版本。

看这段代码：

cpp复制class Base {
public:
    Base() { foo(); }
    virtual void foo() { std::cout << "Base::foo" << std::endl; }
};

class Derived : public Base {
public:
    void foo() override { std::cout << "Derived::foo" << std::endl; }
};

int main() {
    Derived d;  // 输出 Base::foo
}

为什么输出的是 Base::foo？因为构造一个 Derived 对象时，编译器生成的构造流程是先构造基类部分，再构造派生类部分。基类构造函数执行时，对象的 vptr 还被设为基类的 vtable，根本看不到派生类的重写。只有进入派生类构造函数之后，vptr 才会被更新为派生类的 vtable。析构的时候则是反向：先执行派生类析构，再执行基类析构，vptr 在基类析构阶段也早已切回基类虚表。

所以正确的认知是：vptr 在对象的生命周期内是“动态变化”的，它会按照构造/析构顺序被逐步改写，并不是一出生就定死。

那构造函数为什么不能是虚函数？理由其实有两个层面。第一，虚函数调用的媒介 vptr 还需要先执行构造函数才能初始化，对象还没生成完，vptr 无从谈起。第二，调用构造函数时，对象的动态类型尚不明确，虚函数机制本身就无法给出一个确定的目标。这两个原因叠加起来，构造函数注定了不能是 virtual。

至于析构函数为什么建议是虚的：如果基类析构函数不是虚函数，那么通过基类指针 delete 一个派生类对象，在标准层面属于未定义行为。常见编译器的实际表现是只调用基类析构函数，派生类里分配的内存、持有的资源就会泄漏。把基类析构声明为 virtual，delete 才能先调用派生类析构、再调用基类析构，完整释放整个对象。这也是为什么几乎所有的抽象类都会写 virtual ~Base() = default;。

我最初自己在这个地方吃过亏：写插件系统时，基类忘了虚析构，结果每个插件卸载都泄漏几 KB 内存，用 valgrind 查了半天才发现是缺了一个 virtual。这类问题编译器不报错，只能靠规范培训和 code review 拦。

3. 继承体系里的多态链：覆盖、隐藏与切片

3.1 派生类是如何“改写”虚表的

理解了 vtable 和 vptr 基本概念后，再看派生类和虚表的互动就顺理成章了。假设上面那个 Animal 下面加一个派生类：

cpp复制class Cat : public Animal {
public:
    void speak() override { std::cout << "Meow" << std::endl; }
    // move 不重写
};

编译器为 Cat 生成 vtable 时，会先继承 Animal 的虚表布局，然后对重写的函数做替换：speak 的槽位不再指向 Animal::speak，而是指向 Cat::speak。move 没有重写，所以槽位里仍然是 Animal::move 的地址。如果派生类新增了自己的虚函数，它会被追加到虚表的新槽位上。

所以“覆盖”这件事，在内存层面的本质就是：派生类 vtable 里对应槽位的函数指针被替换成派生类自己的实现。调用方通过基类指针 Animal* 调用 speak 时，从对象里找到 vptr，再通过 vptr 跳到 vtable 的 speak 槽位，拿到的实际地址已经是 Cat::speak。

这也是为什么虚函数机制能绕过一个“指针类型是基类”的限制——它真正依赖的是对象的真实类型，而不是指针的静态类型。指针的静态类型只决定你能访问哪些成员，动态调用则交给对象内存里的 vptr 去裁决。

3.2 override、重载、隐藏：三兄弟别搞混

继承体系下有四个概念经常被放在一起比较：覆盖（override）、重载（overload）、隐藏（hide）和屏蔽。

重载指的是同一个作用域内，函数名相同、参数列表不同的多个函数，编译期根据实参选择。覆盖指的是派生类中重写基类虚函数，要求函数名、参数列表、const 属性都一致。隐藏则是派生类中定义了与基类同名的函数，它可能不是在重写虚函数，但会把基类同名函数从外部访问中“藏起来”。

隐藏是个非常容易踩的坑。看这个例子：

cpp复制class Base {
public:
    void func(int x) { std::cout << "Base::func(int)" << std::endl; }
};

class Derived : public Base {
public:
    void func(double x) { std::cout << "Derived::func(double)" << std::endl; }
};

int main() {
    Derived d;
    d.func(42);  // 编译不通过？不，调用 Derived::func(double)
}

func(42) 传入的是整数，但编译器在 Derived 作用域先找到了 func(double)，而 Base::func(int) 已经被隐藏了，于是它宁可把 42 转成 double，也不会去找 Base::func(int)。这就是隐藏带来的坑，它与多态无关，但经常出现在多态相关的代码 review 里。若要调用基类版本，必须显式写 d.Base::func(42)。

我再补充一个小表格，方便对比：

3.3 对象切片：按值传递是动态多态的头号杀手

多态依赖的是对象的真实类型，但“真实类型”只有通过指针或引用才能感知。如果你按值传递一个派生类对象给形参为基类的函数，C++ 会调用基类的拷贝构造函数，把派生类对象“切割”成基类对象。派生类新增的数据成员全部丢失，vptr 被改成基类的 vtable，多态当场失效。

cpp复制void describe(Animal a) {  // 按值传参
    a.speak();  // 永远调用 Animal::speak
}

Cat c;
describe(c);  // 输出 Animal::speak，不是 Meow

这种行为叫对象切片，是面试里一个典型陷阱。解决方式很简单：传引用或指针。引用底层还是地址，不涉及对象拷贝，所以 vptr 不会被改写，动态绑定能正常进行。

我建议把这个点牢牢记在心里，因为实际项目里很容易发生：某个接口接收的不是基类引用而是基类值，传进去的子类对象所有特性都被静默丢弃，问题还特别难排查——编译通过、运行不报错，只是逻辑不对。真遇到这种场景，先怀疑是不是切片了。

4. 纯虚函数、抽象类与接口设计

4.1 纯虚函数在虚表里到底长什么样

纯虚函数 = 0 的语法大家都不陌生，但很少有人关心它在 vtable 里到底占什么位置。在常见编译器的实现中，纯虚函数对应的 vtable 槽位并不是空指针，而是指向编译器生成的一个内部函数。以 GCC/Clang 的 Itanium ABI 为例，这个函数叫 __cxa_pure_virtual，一旦被调用，程序通常直接中止（abort）。也就是说，纯虚函数的“无实现”在底层是一个“防止误调用的哨兵”。

这里有个冷门但很有用的知识点：纯虚函数也可以提供实现。你可以这样写：

cpp复制class Shape {
public:
    virtual void draw() = 0;
};

void Shape::draw() {
    std::cout << "Shape::draw" << std::endl;
}

class Circle : public Shape {
public:
    void draw() override {
        Shape::draw();  // 显式调用纯虚函数的默认实现
        std::cout << "Circle::draw" << std::endl;
    }
};

虽然 draw 被标记为纯虚，但它仍然可以有一个函数体。派生类可以选择显式调用 Shape::draw() 作为“默认处理”，这就是一种很优雅的模板方法模式。不过需要注意，这个调用必须显式带上类名限定符，因为正常虚调用还是会走到纯虚哨兵那里，必然导致程序中止。

4.2 抽象类当接口用，C++ 的推荐姿势

C++ 没有独立的关键字 interface，通常用“只包含纯虚函数 + 虚析构函数的类”来扮演接口角色。一个标准的最小接口长这样：

cpp复制class ISorter {
public:
    virtual void sort(int* arr, size_t n) = 0;
    virtual ~ISorter() = default;
};

为什么要加 virtual ~ISorter()？因为接口永远是通过指针或引用使用的，如果你不把析构声明为虚函数，用户通过 ISorter* 释放真正的派生对象时就会触发未定义行为，资源就泄漏了。= default 让编译器生成默认的析构函数体，同时保留虚函数属性。

一个经典应用就是策略模式：对不同场景用不同算法，但调用方只依赖接口。比如冒泡排序和快速排序都实现 ISorter，运行时根据数据量大小选择用哪个策略加入调用链：

cpp复制class BubbleSorter : public ISorter {
public:
    void sort(int* arr, size_t n) override {
        for (size_t i = 0; i < n - 1; ++i)
            for (size_t j = 0; j < n - i - 1; ++j)
                if (arr[j] > arr[j + 1]) std::swap(arr[j], arr[j + 1]);
    }
};

class QuickSorter : public ISorter {
public:
    void sort(int* arr, size_t n) override { /* 快排实现 */ }
};

调用方持有 ISorter*，运行时把 BubbleSorter 换成 QuickSorter，业务代码一行都不用改。这就是多态在“策略替换”场景下的典型价值。

4.3 实战：用多态组织一个游戏角色技能系统

前面那些概念如果串成一个完整例子，游戏技能系统应该是最直观的。技能的本质就是“不同的技能对象，在释放时有完全不同表现”，这天然适合多态建模。

先定义一个抽象技能接口：

cpp复制class Skill {
public:
    virtual void use(GameCharacter& owner, GameCharacter& target) = 0;
    virtual std::string name() const = 0;
    virtual ~Skill() = default;
};

然后实现几个具体技能，比如火球术、治疗术：

cpp复制class FireBall : public Skill {
public:
    void use(GameCharacter& owner, GameCharacter& target) override {
        target.takeDamage(owner.magicPower() * 2);
        // 播放火球特效、音效
    }
    std::string name() const override { return "FireBall"; }
};

class Heal : public Skill {
public:
    void use(GameCharacter& owner, GameCharacter& target) override {
        target.restoreHealth(owner.magicPower());
        // 播放治疗特效
    }
    std::string name() const override { return "Heal"; }
};

玩家的技能列表用 std::vector<std::unique_ptr<Skill>> 存储：

cpp复制std::vector<std::unique_ptr<Skill>> skills;
skills.push_back(std::make_unique<FireBall>());
skills.push_back(std::make_unique<Heal>());

for (auto& skill : skills) {
    skill->use(player, enemy);
}

这样做的好处非常明显：新增第三种技能（比如雷击术）时，只需要写一个新类并实现 use 和 name，然后往 vector 里塞一个 unique_ptr。技能释放主循环完全不需要修改，既避免了 if-else 膨胀，又把每个技能的行为收敛在自己类内部。配合前面提到的虚析构，unique_ptr 在 vector 析构时会自动调用每个技能对象的完整析构链，不会泄漏。

很多游戏框架的 buff、debuff、技能、任务系统，底层都是这种抽象接口加多态分发的结构。理解了这套东西，去读一些开源游戏项目里的核心模块会顺手很多。

5. 多态的隐藏成本：性能、内存与编译器优化

5.1 一次虚函数调用的真实执行路径

很多人知道“虚函数比普通函数慢”，但具体慢在哪，多数人说不清楚。从汇编视角看，普通函数调用是一个相对地址的 call，指令里直接写目标地址；而虚函数调用至少需要三步：

asm复制mov rax, [rdi]        ; 1. 从对象头取出 vptr
mov rcx, [rax + 16]   ; 2. 从 vtable 偏移处取出函数地址
call rcx              ; 3. 间接调用

也就是说，多出两次间接内存访问，最终那次 call 还是跳到一个从内存里拿到的地址上。CPU 的分支预测器对这种间接跳转的预测成功率，远不如普通函数调用那么稳定。在微基准测试里可能看不出差别，但在一个高频循环里、每帧执行几十万次虚调用时，这个差距会被明显放大。

我之前优化过一个网络消息分发模块：原来是基于虚函数的 MessageHandler 基类，每个消息一个派生类，高峰期在一台机器上每秒要分发几十万条消息。profile 结果显示这个分发路径消耗了将近 15% 的 CPU。后来我把消息处理改成注册函数指针的静态表，跑分立刻降了一半多。不是说多态不行，而是在这种极热路径上，你真得算清楚它的成本。

5.2 内存开销与缓存友好性

多态的内存开销有两块。第一块是每个对象都要多一个 vptr，一个类如果有虚函数，每个实例就多出 8 字节（64 位平台）。如果对象数量是百万级，这 8 字节就变成了 8MB 额外内存。第二块是多重继承下的 vptr 数量：一个派生类继承多个含虚函数的基类时，常见实现中会持有多个 vptr，分别指向不同基类子对象的 vtable。这会进一步破坏数据布局的紧凑性。

对性能敏感的系统，缓存友好性也很重要。当你用一个 std::vector<Base*> 存多态对象时，对象本身散落在堆各处，访问时无法像连续数组那样顺序读取，cache miss 会明显增加。相比之下，std::vector<ConcreteObject> 的数据是连续排列的，遍历时预取效率高得多。这也是为什么很多高性能引擎在热路径上会刻意避免虚函数和指针数组，改用紧凑的 struct、组件数组（ECS 风格）或者模板。

5.3 多态的适用边界：什么时候别硬上

多态是工具，不是银弹。我的经验是，以下两类场景需要慎重考虑：

第一是热路径。比如渲染循环、每帧都要调用的更新逻辑、高频消息分发。这类场景如果类型集合在编译期就确定，优先考虑模板或者 std::variant + std::visit。C++17 的 std::variant 本质是一个带类型安全标记的联合体，std::visit 在底层会生成一张跳转表，和虚表有异曲同工之妙，但它把数据和标记紧凑地放在一起，缓存友好性更好，而且没有堆分配。

第二是“永远不会变化”的类型体系。如果只有一两个派生类、而且未来几乎不会新增，那用多态更像过度设计。我见过不少代码为了“以后扩展方便”先抽出一堆抽象接口，结果五年后还是只有最初的两个实现，抽象接口反而拖慢了阅读和维护。设计原则讲究 YAGNI（You Ain't Gonna Need It），多态的使用也适用。

6. 面试高频问题与项目避坑经验

6.1 面试里关于“多态”的死问题，逐个击破

面试官问多态，翻来覆去就是这几道题，我把高频的整理出来：

虚函数表有几份？每个对象一份吗？ 不是。vtable 是类级别的一份，所有同类对象共享；每个对象只是持有一个 vptr 指向这张共享表。

有虚函数的类，sizeof 为什么比实际数据成员大？ 因为对象头多了一个 vptr 指针，还可能因为内存对齐补充 padding。

构造函数为什么不能是虚函数？ 虚调用依赖 vptr，而 vptr 必须由构造函数链初始化；在对象构造完成前，动态类型尚未确立，vptr 也尚未就绪。

析构函数为什么通常要 virtual ？ 当通过基类指针删除派生类对象时，若析构非虚，行为是未定义的；常见表现是只析构基类部分，导致派生类资源泄漏。

构造函数/析构函数里调用虚函数会发生什么？ 不会走虚分派，只会调用当前正在构造/析构的类的版本。原因是 vptr 按构造/析构顺序被逐步切换。

多重继承下 vptr 怎么处理？ 常见实现里，一个派生类会包含多个 vptr，分别指向各基类子对象对应的 vtable。这也是为什么多重继承会让对象尺寸显著增大、调用路径更复杂。

成员函数模板可以是虚函数吗？ 不可以。虚函数的表项数量需要在编译期确定，而模板是惰性实例化的，两者天然冲突。类模板可以包含虚函数，但虚函数本身不能是模板。

typeid / dynamic_cast 底层依赖什么？ 依赖 RTTI。在常见实现中，编译器会利用 vptr 找到类型信息结构，从而支持运行期类型判断和安全的向下转型。

6.2 实际项目中，我遇到过的三个经典坑

第一个坑是基类析构函数忘记 virtual。前面讲过逻辑，这里只提一个场景：写插件系统时，基类定义得很轻量，觉得“内部没有资源要释放，不需要虚析构”。结果插件加载一批后，内存持续上涨，valgrind 报告一批可疑泄漏。排查后发现所有派生类的成员对象都没被析构。从那次以后，我给自己定了一条硬规则：凡是设计了虚函数且有派生类的类，析构函数一律加 virtual，无论看起来有没有资源需要释放。

第二个坑是在构造函数里调用虚函数做初始化。比如基类构造里调用某个虚函数去“配置自己的行为”，期望派生类重写后能按子类逻辑初始化。结果是静默失败：调用的是基类版本，子类配置压根没执行。这个问题非常隐蔽，编译不报错、运行不崩溃，就是行为不对。正确做法是把延迟初始化放到派生类构造完成后，或者用模板方法模式提供一个非虚的 init() 钩子，并在基类构造函数中调用非虚函数，再由非虚函数内部调用虚函数。但记住，构造函数调用虚函数永远不是动态绑定。

第三个坑是按值传递多态对象导致切片。这在我之前的文章里提过，这里强调一下：排查这个问题时，直接在函数参数类型里找 ClassName x 就可以了，凡是形参不是引用/指针而是一个类类型的，都是在走拷贝，多态必然失效。

6.3 我写多态代码的几个习惯

最后一个环节分享几个个人习惯，谈不上金科玉律，都是实践中沉淀下来的。

第一，不急着抽象。我通常先写出具体实现，跑通逻辑之后再回头抽接口，而且只抽“未来真的会变”的部分。很多过度设计都是因为在一开始就脑补了一堆扩展场景，结果根本没有发生。抽象发生在有真实痛点之后，而不是在想象中。

第二，重写虚函数一律加上 override。这不仅是风格问题。编译器会在参数列表不匹配、函数不是虚函数时直接报错，避免你“以为覆盖了其实没有”。final 也是一样，明确不打算被继承的类就写死，既给编译器 devirtualize 的机会，也给读者语义提示。

第三，对象生命周期用 unique_ptr + 虚析构。C++ 类的多态场景，我几乎不用裸 new/delete 管理对象。unique_ptr<Base> 天然支持派生类的完整析构链，只要你把基类析构声明为虚函数，内存释放就交给 RAII 处理。

第四，性能问题先用 profile 证明，再动手重构。不要因为“感觉虚函数慢”就把所有接口从虚函数改成模板。先跑 profilig，确认虚调用确实在瓶颈路径上，再考虑用 std::variant、模板或函数表替换。盲目优化常常引入更复杂的代码，最后收益却很小。

最后再提一个小技巧：调试虚函数问题时，打印对象的地址和虚表地址会很有帮助。你可以在代码里把对象的首地址强制转换成 void**，第一个元素就是 vptr 的值，vptr 指向的数组里就是各个虚函数的地址。用 GDB 或 LLDB 的 set print object on 也能直接看到动态类型。理解这个底层视角后，多态就不再是黑盒了。