企业官网建设流程全解析

C++ 的多态，如果你能把它讲透，基本上面试里关于面向对象的部分就能过关。但现实情况是，很多学了一年半载的朋友，说起“封装、继承、多态”就跟背口诀一样，知道有这回事，代码一写就露馅。前几天我系统性梳理了一遍多态相关的知识点，从概念到实现、从拓展到原理，干脆整理成一篇完整的笔记。这篇文章不打算只讲虚函数那几个字怎么拼，想把它讲成人话，告诉你这东西到底解决了什么问题、底层是怎么转起来的、用的时候有哪些地方容易翻车。

先说个大白话定义：多态，就是“同一个接口，多种形态”。放到 C++ 里，最常见的表现形式是——你拿一个基类的指针或引用，去调用一个虚函数，程序会根据这个指针/引用实际指向的对象的真实类型，决定调用哪一个版本的函数。基类说一句话，不同的派生类按自己的方式执行。听起来抽象，你想想“动物都会叫”这件事：猫叫是“喵”，狗叫是“汪”，你对着一个“动物”的指针喊“叫！”，它到底是按猫叫还是按狗叫，取决于你手里的指针到底指向猫还是狗。这就是多态的核心。

这套东西适合谁看？已经学过 C++ 语法、接触过类和对象但还没有把“多态”和实际场景串起来的人。如果你是零基础，我建议先过一遍类的继承内容再来看这篇。本文会从设计思路讲起，逐步深入到虚函数表（vtable）、构造函数里调用虚函数的坑、多继承下的布局问题、抽象类设计等，最后附上一些面试常见的排查场景。文章较长，但可以收藏起来分段看。

1. 先搞懂多态到底在解决什么问题

1.1 没有多态的世界会怎样

假设你要做一个绘图程序，需要支持画圆形、矩形、三角形。如果不用多态，每个图形类都得写自己的draw()成员函数。当你需要一个"图形列表"，然后统一把它们画出来时，麻烦就来了：你得用一堆if-else判断每个对象的类型，然后单独调用对应的函数。看一眼就知道这种代码有多难受。

void drawAll(vector<Shape*>& shapes) { for (auto* s : shapes) { if (typeid(*s) == typeid(Circle)) { static_cast<Circle*>(s)->drawCircle(); } else if (typeid(*s) == typeid(Rectangle)) { static_cast<Rectangle*>(s)->drawRectangle(); } // 每加一种新图形，就要改这里 } }

这种代码的问题不只是丑，它还违反了开闭原则：每增加一个新的图形类型，你得回头修改drawAll()这个函数。而面向对象设计追求的是“对扩展开放，对修改关闭”。多态就是为了解决这个问题出现的。

有了多态之后，drawAll()只需要认识Shape，并且调用s->draw()。至于s真正是谁、它内部怎么画，基类完全不关心。将来新增五角星类，只需要写一个继承Shape的Star，实现自己的draw()，drawAll()一行不用改。这就是多态最大的价值：把“变”和“不变”分离。

1.2 静态联编与动态联编的本质差异

C++ 里有两种“绑定”方式。函数调用如果能在编译期就确定具体调哪个版本，叫静态联编；如果编译期确定不了，需要等到运行期根据实际对象类型才能确定，叫动态联编。多态依赖的正是动态联编。

举一个容易让人迷惑的对比：

class Base { public: void func() { cout << "Base::func" << endl; } virtual void vfunc() { cout << "Base::vfunc" << endl; } }; class Derived : public Base { public: void func() { cout << "Derived::func" << endl; } void vfunc() override { cout << "Derived::vfunc" << endl; } };

看看执行结果的区别——这是新手最容易踩的第一个坑。

int main() { Derived d; Base* p = &d; p->func(); // 输出 Base::func，因为 func 不是虚函数，编译期就绑定了 p->vfunc(); // 输出 Derived::vfunc，因为 vfunc 是虚函数，运行期动态绑定 }

这个差异说明了两件事。第一，非虚函数由“指针的静态类型”决定调哪个版本；第二，虚函数由“对象的真实动态类型”决定调哪个版本。很多人在Base* p = &d;之后发现p->func()调的是基类版本，就觉得 C++ 莫名其妙，其实这只是还没理解虚函数和非虚函数在绑定时机上的区别。

1.3 面试和实战里多态为什么绕不开

打开任何一份 C++ 岗位的面试题，几乎都会问“多态怎么实现”“虚函数表是什么”“构造函数里能调用虚函数吗”“析构函数为什么需要虚化”。这已经成了 C++ 基本功的硬指标。而实际上，做大型项目的时候，基于抽象基类的设计风格几乎无处不在——从插件系统、策略模式，到 Qt 的信号槽事件模型，再到游戏引擎里的组件系统，全都依赖多态。学多态不光是应付面试，更是在为理解主流 C++ 框架的源码打基础。

2. 多态底层原理：虚函数表与虚指针

2.1 虚函数表到底是怎么工作的

C++ 标准并没有规定编译器必须用什么方式实现动态多态，但主流编译器（GCC、Clang、MSVC）不约而同地选择了“虚函数表（vtable）+ 虚指针（vptr）”的方案。理解这套机制，就是理解多态原理的关键。

先放结论：每个含有虚函数的类，编译器都会为它生成一张虚函数表。这张表是一个数组，数组中存放的是该类的所有虚函数的地址。每个含有虚函数的对象内部，会有一个隐藏的指针vptr，构造函数自动把它指向所属类的虚函数表。当程序通过基类指针调用虚函数时，实际执行的动作是：先从对象里取出 vptr，再通过 vptr 找到虚函数表，在表里取出对应槽位的函数指针，然后间接调用。这里面每一步都涉及内存寻址，所以虚函数调用比普通函数调用多一层间接开销。

看一个经典例子。假设有这样一个继承体系：

class Animal { public: virtual void speak() { cout << "Animal speak" << endl; } virtual void move() { cout << "Animal move" << endl; } }; class Dog : public Animal { public: void speak() override { cout << "Dog speak: wang!" << endl; } void move() override { cout << "Dog move: run!" << endl; } };

内存中的直观理解是这样的：Dog 类自己的虚函数表和 Animal 的虚函数表不是同一张，但它们的表项排列顺序是一致的——第一个槽位放 speak，第二个放 move。Dog 的 speak 槽被覆盖成了 Dog 版本的地址，move 槽也被覆盖成 Dog 版本的地址。Dog 对象内部有一个隐藏 vptr，指向 Dog 的虚表。你用Animal* p = &dog; p->speak();的时候，p 虽然静态类型是 Animal，但运行时它实际拿到的对象是 Dog，对象里的 vptr 指向 Dog 的虚表，所以取出来的是 Dog::speak 的地址。这就是“实际调用哪个版本由对象自身决定”的底层逻辑。

2.2 虚表继承时的覆盖关系

我再用个表格帮大家把“覆盖”这个动作梳理清楚。假设基类有三个虚函数 A、B、C，派生类只重写了 B 和 C，没有重写 A。

这就是虚函数表里的“覆盖”逻辑：重写一个虚函数，就是把派生类虚函数表里对应位置的函数指针替换成自己的版本。注意，虚表本身是以类的粒度存在的，不是以对象的粒度存在。同一类的所有对象共享同一张虚函数表，但每个对象各自保存一个指向该表的 vptr。好多人误以为每个对象都有一张虚表，这是不对的。对象之间共享虚表，节省内存，但 vptr 各自持有，因为只有这样运行时才知道这个对象到底是谁。

2.3 构造过程中 vptr 的变化和那个经典大坑

这里有个隐藏细节，理解之后能解释很多诡异的现象：vptr 在对象构造过程中不是一成不变的，它随着构造层级的变化而改变。

想象一下构造一个 Dog 对象的过程。程序先进入 Animal 的构造函数，此时对象的内存布局还只是基类部分，编译器会让 vptr 指向 Animal 的虚函数表。等 Animal 构造函数体执行完，编译器再让 vptr 指向 Dog 的虚函数表，然后才进入 Dog 的构造函数体。这个动态调整意味着：在基类构造函数执行期间，你调用一个虚函数，它并不会触达派生类的版本，因为此时 vptr 还在指向基类的虚表。

class Animal { public: Animal() { speak(); } // 这里调用虚函数，会调用哪个？ virtual void speak() { cout << "Animal speak" << endl; } }; class Dog : public Animal { public: void speak() override { cout << "Dog speak" << endl; } }; int main() { Dog d; // 猜猜构造过程中输出什么？ }

执行结果是输出Animal speak。因为构造 Dog 的时候，先执行 Animal 的构造函数，此时 vptr 指向 Animal 的虚表，speak()只能查到 Animal 的版本。很多人不懂这个原理，写了在基类构造函数里调用虚函数的代码，以为能“让基类构造函数调用派生类方法”，结果没有生效，百思不得其解。这里给你一个明确结论：构造函数里调用虚函数不会产生多态行为，别这么设计。我第一次踩这个坑是在写一个初始化缓存模块的基类时，当时想在基类构造函数里根据不同类型走不同的初始化逻辑，结果六个派生类全部走了同一个分支。查了半天才发现是整个构造顺序决定的：你调用它的时候，派生类那部分还没被构造出来，对象里压根还没有派生类的东西，怎么可能调用到派生类的函数呢。从逻辑上讲也是合理的——子类还没造好，你强行调用子类的方法，这不现实。

3. 多态的实现落地：从虚函数到抽象类

3.1 用 override 修饰符写好重写

C++11 开始有了override关键字，强烈建议每个重写虚函数的地方都加上。它不是语法必需品，但它能帮你在编译期发现很多低级失误。比如你想重写基类的virtual void draw()，结果基类里其实写的是void Draw()，你这边写void draw() override，编译器就会直接报错“没有可重写的函数”。没有override，编译器可能什么警告都不给你，这个函数就成了隐藏，而不是重写。你还是能在运行时得到“基类指针调用了基类函数”这种莫名其妙的结果，排查很久才头发现是函数签名大小写不匹配。

来看一个标准写法：

class Shape { public: virtual double area() const = 0; virtual void draw() const { cout << "draw shape" << endl; } virtual ~Shape() = default; }; class Circle : public Shape { private: double radius; public: explicit Circle(double r) : radius(r) {} double area() const override { return 3.14159 * radius * radius; } void draw() const override { cout << "draw circle" << endl; } };

这里有几个细节值得展开说。第一，基类里area()声明成纯虚函数（末尾的= 0），说明它没有实现或者不想被直接实例化。第二，override加在派生类里，编译期检查签名匹配；函数签名包括参数列表、const 限定符等，基类函数带const，派生类不带const也会判定失败。我见过有人写了void draw() override去重写基类里void draw() const override的情况，然后在多态调用里半天调不对，最后发现是 const 修饰不匹配。第三，析构函数加virtual的问题是常规操作，后面专门讲。

3.2 多态只对指针和引用生效

C++ 多态有一个重要限制：它必须通过指针或引用来使用。如果你把对象直接赋值给另一个对象，发生了“切片”，多态就没了。看下面这个例子：

void printArea(Shape s) { // 参数是 Shape，传 Circle 进来会切片 cout << s.area() << endl; } Circle c(5.0); printArea(c); // 这里调用的是 Shape::area()

因为参数按值传递时会调用Shape的拷贝构造函数，把Circle中派生类的部分切割掉，只保留基类部分。这时候对象就是一个普通的 Shape，vptr 指向 Shape 的虚表，多态也就无从谈起。解决办法很简单：把参数改成Shape&或者Shape*，这是实际开发中最常见的错误之一。

3.3 抽象类与接口设计

当一个类至少有一个纯虚函数时，它就是抽象类，不能直接实例化。

Shape s; // 编译错误：不能实例化抽象类

这其实是好事，强制你使用抽象类作为“接口”来写多态逻辑。说到“接口”，C++ 里没有 Java 那样的 interface 关键字，但我们可以统一用“全部是纯虚函数”的类来模拟接口。比如定义一个Drawable：

class Drawable { public: virtual void draw() const = 0; virtual ~Drawable() = default; };

任何类只要继承Drawable，就必须实现draw()。这样业务代码可以只依赖Drawable指针，而不必关心具体图形类是谁、内部结构长什么样。这在大型项目里很好用，因为模块之间可以解耦。分享一个我在实际项目中的做法：设计权限管理模块时，定义一个IAuthentication接口，里面有login()、logout()、checkPermission()三个纯虚函数，分别让PasswordAuth和TokenAuth去实现。后续要加指纹验证，只需要新增一个类继承接口，主流程代码完全不用动，完全可以达到“对扩展开放，对修改关闭”的效果。

3.4 虚析构函数：为什么必须虚

这可能是多态里最重要的一条铁律：只要一个类会被当作基类来使用，或者有人通过基类指针delete派生类对象，基类析构函数就必须是virtual。为什么？看这段代码：

class Base { public: ~Base() { cout << "Base destroyed" << endl; } }; class Derived : public Base { private: int* data; public: Derived() : data(new int[100]) {} ~Derived() { delete[] data; cout << "Derived destroyed" << endl; } }; int main() { Base* p = new Derived(); delete p; // 只调用了 Base 的析构函数 }

这里Base的析构函数不是虚函数，所以delete p时根据指针静态类型走的是Base::~Base()，Derived的析构函数根本不会执行，data这块内存就泄露了。把析构函数声明为virtual之后，delete p会沿着虚表找到真正的析构函数（派生类析构会隐式调用基类析构），资源才能全部释放。

我有个建议：给自己的类写好析构函数前，先问三个问题：这个类会被继承吗？这个类会被用基类指针管理吗？我用virtual是不是零成本？只要“会被继承”这一点成立，析构函数就直接virtual，不要犹豫。这里也不存在“先别加 vptr，等以后再加”这种优化空间，因为一旦类里已经存在任何虚函数，vptr 早就存在了，析构函数加不加 virtual 对对象布局几乎没影响。

3.5 静态成员和友元：不参与多态的部分

这个问题偶尔有人问：静态成员函数能不能是虚函数？不能。因为静态成员函数不依赖对象实例，没有 this，没有 vptr 可以借用，虚函数调用的基本前提就没有了。友元函数也不能是虚函数，因为友元不属于任何类，自然也没有“重写”这回事。这两个点记住结论就行，面试偶尔会考概念题。

4. 深挖拓展：多继承、RTTI、模板与多态家族

4.1 多继承下的虚函数表布局到底长什么样

单继承下虚表结构还算好理解，多继承的虚表就复杂多了。C++ 里一个派生类如果有多个有虚函数的基类，那么这个派生类对象里会有多个 vptr，每个 vptr 指向不同的虚函数表。听起来有点绕，你用脑子干想容易乱，不如看图概念。假设有Base1和Base2两个基类，各自有虚函数；Multi : public Base1, public Base2继承了它们。Multi对象里会同时存在 Base1 子对象的 vptr 和 Base2 子对象的 vptr。Base1* p1 = &multi能通过第一个 vptr 找到Multi对Base1::func的重写；Base2* p2 = &multi则通过第二个 vptr 找到Multi对Base2::func的重写。

多继承里还容易出现“菱形继承”的问题：A是基类，B和C都继承A，D又同时继承B和C，于是D里有两个A子对象，访问同一个A成员时会产生二义性。解决办法是虚继承（virtual继承关键字），但这又会让虚函数表布局更复杂，而且不同编译器的实现细节差异更大。我的建议是：日常业务开发尽量少用多继承，确实需要接口分离时多继承接口类即可，因为接口类没有数据成员，菱形问题会少很多。现代 C++ 里更推荐的组合方式是模板和接口混搭，这个后面说。

4.2 协变返回类型：允许返回类型“改得更具体”

C++ 有一个相对冷门但优雅的机制叫“协变返回类型”。重写一个虚函数时，允许返回类型是指向派生类的指针或引用，而不是必须和基类完全一致。举个工会场景的例子：

class Base { public: virtual Base* clone() const { return new Base(*this); } }; class Derived : public Base { public: Derived* clone() const override { return new Derived(*this); } };

这样写的好处是，当你有一个明确的Derived对象时，调用clone()能直接得到一个Derived*，不需要再手动向下转型。如果是传统的写法，基类返回值是Base*，你拿到之后还得static_cast<Derived*>，多一层麻烦，还容易让人阅读困难。注意协变的限制很严格：返回指针时，要求返回类型是指向派生较重类的指针；返回引用时，要求是引用类型，不能是值类型。值类型返回不是协变，编译器会直接报错。

4.3 RTTI 与安全转型

RTTI（运行时类型识别）是多态机制的一个衍生工具。核心运算符和函数有三个：typeid、dynamic_cast、type_info。

typeid可以返回一个type_info对象，告诉你一个表达式的静态或动态类型。在多态对象下它才有意义，否则返回的多半是静态类型信息。

dynamic_cast是安全向下转型工具。它专门用于多态类型：把一个基类指针转换成派生类指针，如果转换失败，指针版本返回空指针，引用版本抛出bad_cast异常。这是它和static_cast最大的区别——static_cast不做运行时检查，转错了就转错了，不会给你反馈。

应用层一个典型场景是：接口类返回给业务模块，业务模块知道自己拿到的其实是某个具体类型，但又不想乱转，就调用using *derivedPtr = dynamic_cast<Derived*>(basePtr); if (derivedPtr) { ... }来检查一下。但我要提醒一句：RTTI 的dynamic_cast是开销较高的操作，因为它要查类继承关系链，而且底层还依赖虚函数表。在高频循环里大量使用dynamic_cast，对性能肯定有影响。更坏的是它还容易让代码变得很“类型跳来跳去”。我自己代码里用得少，只有在第三方的接口类自己无法定义虚函数时，才被迫用它来做类型甄别。如果能从设计上避免，尽量在设计接口时多放几个虚函数“把类型行为封装进去”，会比“拿到类型再分支”高明得多。

4.4 智能指针如何搭配多态使用

现在写新代码基本都建议用unique_ptr和shared_ptr管理资源，多态场景下也一样。常见写法是把基类指针放进智能指针：

unique_ptr<Shape> s = make_unique<Circle>(3.0); s->draw();

这里有一个关键点：智能指针的析构行为。unique_ptr<Shape>默认使用的删除器是default_delete<Shape>，当对象析构时，它会根据Shape是否是多态基类来决定是否调用虚析构。如果你在基类上定义了虚析构函数，unique_ptr<Shape>析构时会透过虚表调用真正的派生类析构函数，资源释放正确。如果你忘记写虚析构，即使你用了智能指针，析构时依然不会调用派生类析构，内存照样泄露。所以，虚析构的问题在任何一种管理方式下都不可忽视。

另外还有一个配合多态的常见需求：拷贝对象。如果你用shared_ptr<Shape>存了一堆图形，现在想要每份的独立副本，典型的做法是在基类里提供clone()纯虚函数，返回shared_ptr<Shape>之类的语义类型。因为纯虚函数保证了每个派生类都必须给出自己的实现，所以拷贝行为不会走偏。

4.5 模板与多态的竞争：静态多态的另一种思路

C++ 里的“多态”分两种：我们前面讲的是运行时多态（动态多态），基于虚函数；另一种是编译期多态（静态多态），基于模板。模板也能实现一种“看起来多态”的效果，比如你写一个模板函数，不管传入什么对象，只要它有draw()方法，就能调它：

template <typename T> void drawIt(const T& obj) { obj.draw(); }

模板多态的好处是零虚函数开销，编译器在编译期就能确定具体调用哪个函数，几乎可以内联展开。坏处是“类型”不再统一，你不能把一个Circle和一个Rectangle塞进同一个vector<>里（除非用variant或者类型擦除）。所以两种策略各有各的适用场景：框架边界需要统一类型、需要扩展性时，用虚函数多态；算法内部、性能敏感但类型集合固定时，用模板多态比较合适。我日常写引擎工具时也用一个小技巧：模板提供通用极简代码，虚函数接口作为边界抽象，两者互为补充。

5. 高频踩坑与问题排查速查

5.1 重写、重载、隐藏的区分

这个可以说是 C++ 面向对象面试里最经典的问题，没有之一。三个术语长得像，含义完全不同：

隐藏出现的场景特别容易绕进去。我给一个口诀：同名 + 不同参 = 重载或者隐藏；同名 + 同参 + 基类有 virtual = 重写；同名 + 同参 + 基类无 virtual = 隐藏。隐藏是很多人代码跑出“奇怪结果”的根源。我见过有人在一个非虚的基类函数上加了同名同参的派生类函数，然后通过基类指针去调用，结果调用了基类的版本，他觉得 C++ 不靠谱。其实这不是 bug，就是隐藏，编译器按静态类型办事。

5.2 用基类指针数组管理派生类对象时的删除隐患

这是一类实战中特别常见的崩溃/内存问题。看代码：

vector<Base*> objs; objs.push_back(new Derived1()); objs.push_back(new Derived2()); for (auto* p : objs) delete p; // 如果 Base 析构不是 virtual，直接内存泄漏

解决方案就是在Base上放一个virtual ~Base() = default;。一行代码解决。但这里还有另一个容易忽略的点：如果Base不是多态类（没有虚函数），编译器会直接对delete p产生 UB（未定义行为），因为标准要求通过基类指针删除对象时，基类必须有虚析构函数。别小看这句话，Windows 上它可能表现为随机崩溃，而排查起来非常痛苦。

5.3 在构造函数和析构函数里调用虚函数

前面已经解释过构造阶段 vptr 变化的问题，结论再强调一遍：不要期待构造函数或析构函数里出现动态多态。构造函数里调用虚函数，只会调用当前正在构造的这一层的函数版本；析构函数同理——析构外层时，派生类成员已经被释放了，vptr 已经指回基类虚表，多态同样失效。

实际应用时我建议制定一条团队约定：构造函数和析构函数里一律不调用虚函数。如果确实需要“根据子类类型初始化基类资源”这种需求，老老实实把参数传给基类构造函数，或者在构造完成之后单独调一个初始化函数，不要让虚函数机制承担它办不到的事。

5.4 误以为加了 virtual 就万事大吉

virtual本身并不自动产生多态，真正产生多态的是“基类指针/引用指向派生类对象 + 虚函数的组合”。如果你只是调用了派生类对象的成员函数，其实调用的就是派生类自己的函数，谈不上多态。多态的关键在于调用方的“静态类型”与对象的“动态类型”不一致。所以判断一段代码有没有多态性，直接看它是不是用基类类型的指针/引用去操作派生类对象，这一步错了，虚函数写得再规范也没用。

还有一个特别容易忽视的陷阱：当你在成员函数里把一个对象按值返回或者拷贝时，也可能发生切片。比如：

Shape getShape() { Circle c(2); return c; // 切片，返回的是一个 Shape，不是 Circle }

返回类型是Shape而不是Shape&或Shape*，副本构造时已经丢失了派生类信息。这个坑常出现在写工厂函数的人身上，值得一道。

5.5 面试官常问的几个“反直觉”问题

我归纳几个高频问题，附带一个速查答案，你在面试前可以拿来自测：

1. 为什么不能有“虚构造函数”？——构造对象时类型还没确定，vptr 还需要被初始化；而且构造函数里没有对象本体可用，多态调用的基础不存在。

2. 为什么析构函数推荐虚化？——保证delete 基类指针时能调用到派生类析构，避免资源泄漏和 UB。

3. 一个类里有虚函数，它的大小是多少？——一个类通常至少多一个 vptr 大小（64 位下 8 字节），再加上对齐规则可能还有别的填充；继承多个基类就有多个 vptr。

4. 虚函数调用比普通函数慢多少？——慢在一次间接跳转、不能内联、可能需要处理缓存未命中；严格说不是“数量级”差异，但高频热循环里确有影响。

5. dynamic_cast和static_cast在多态下的区别？——前者安全检查，后者无检查；类型不对时前者返回 nullptr，后者是犯罪行为。

5.6 日常排查：多态行为失效怎么定位

在实际调试中，如果发现自己以为的多态没生效，我建议大家按这个顺序排查：

第一步，确认调用方式是指针/引用。只要你是用对象名直接.调用的，比如d.vfunc()，那就不叫多态，那是普通成员函数调用。 第二步，确认基类函数有virtual关键字。漏掉virtual是最常见的低级错误。 第三步，确认派生类的函数签名和基类完全一致。函数名、参数类型、const、&或&&限定符都对才行。 第四步，确认没有发生切片。检查有没有按值传参、按值返回、按值拷贝赋值。 第五步，确认对象是派生类的对象。比如通过reinterpret_cast或 void* 转回来这种操作破坏了对象，你说不清它现在到底是什么。

很多时候你加一个override让编译器帮忙检查，比自己盯着看靠谱得多。我调试多态问题最快的一次就是在拷贝赋值运算符里发现按值赋值导致切片，五分钟定位。这充分说明，切片问题在日常代码里真的随时可能出现。

最后再分享一个我在使用多态时比较极端的检查习惯：在设计阶段我就会把每个“可被继承”的类的析构函数写成virtual。如果这个类里已经有虚函数了，析构写成virtual几乎没有额外成本；如果暂时还没有虚函数，说明这个类暂时不参与多态，后面要加虚函数时提醒自己同步处理。这样几十年下来，我绝大多数资源泄漏问题和 UB 问题都提前被扼杀在代码评审阶段。

多态的底层机制看似烦琐，但只要抓住“虚函数表 + vptr + 动态绑定”这条主线，再配合几个常见坑位的记忆，你就能在实战中覆盖绝大部分场景。写这篇文章是想把它讲透：先讲“为什么需要”，再讲“怎么实现”，然后讲“怎么拓展”，最后讲“底层原理”。希望这篇整理能成为你的上手手册，之后你在看 C++ 框架源码、写插件架构、设计业务模型的时候，都能自然地用上这一套东西。