如果你第一次接触C++的抽象类，大概率是因为写了这样一个类，然后试图直接new它，结果编译器毫不留情地甩出一句“cannot instantiate abstract class”。第一次见到这种“生来就不能实例化”的类型，很多人的第一反应是：C++凭什么这么霸道？其实这背后是抽象类、多态、纯虚函数、虚表机制这一整套设计想让你遵守的规则。
这篇文章我准备把这几个概念放在一起讲透，而不是拆成零散的面试八股。你会看到抽象类到底解决了什么工程问题，纯虚函数的语法边界在哪里，虚表（vtable）在内存里长什么样，多重继承时编译器又是怎么偷偷调整指针的。如果你正在学C++，或者写了不少C++但总觉得“多态”和“虚表”是黑盒，这篇文章值得耐心看完。
1. 为什么要把一个类设计成“不能实例化”：抽象类的价值与多态起点
1.1 从if/else泛滥谈起
我们先回到一个特别常见的场景。假设你要写一个绘图程序，里面有圆形、矩形、三角形。很多人第一版代码会这么干：
enum class ShapeType { Circle, Rectangle, Triangle }; struct Shape { ShapeType type; double radius; double width; double height; }; double calcArea(const Shape& s) { switch (s.type) { case ShapeType::Circle: return 3.141592653589793 * s.radius * s.radius; case ShapeType::Rectangle: return s.width * s.height; case ShapeType::Triangle: return 0.5 * s.width * s.height; } return 0.0; }这个代码能跑，但问题会随着需求增长迅速暴露。每新增一种形状，你都要改calcArea，还要改枚举、改结构体里的字段，甚至可能改好几个地方。更麻烦的是，不同形状的行为可能越来越多：绘制、缩放、序列化、碰撞检测……你会发现switch语句散布在代码库的各个角落，每个都要跟着加一个分支。
这时候你会想到面向对象的多态。让每种形状自己负责自己的面积计算，调用方只需要通过一个统一的接口去调用，运行时会根据实际对象的类型找到对应的函数。这就是动态多态，而实现它的前提，是先有一个定义“契约”的抽象类。
1.2 抽象类与普通类的本质差别：类型契约 vs 实现复用
普通类关心的是“实现复用”：把公共的成员变量和函数放在基类里，子类继承后直接使用。但抽象类关心的是另一个层面的事情：它定义了一种“类型契约”。
class Shape { public: virtual ~Shape() = default; virtual double area() const = 0; };这个Shape类里有一个纯虚函数area()，它只有一个签名，没有实现。它想表达的意思是：凡是继承自Shape的类型，都必须能计算自己的面积。至于怎么算，那是子类的事。
这就是抽象类和普通类的本质差别：
- 普通基类：提供“公共实现”，子类可以借用，也可以覆盖。它通常可以实例化。
- 抽象基类：提供“接口约束”，子类必须实现约定的能力。它不允许实例化。
如果你在C++里试图Shape s;或new Shape()，编译器会直接拒绝，因为一个带着未实现纯虚函数的类型在逻辑上是不完整的。这种“不完整性”恰恰是设计意图：你不需要一个不知道自己是圆还是方的“形状”，你只需要一个能指向任何具体形状的基类指针或引用。
很多初学者容易混淆“抽象类”和“普通带虚函数的基类”。普通基类可以有虚函数，也可以直接实例化；抽象类至少含有一个纯虚函数，因此无法实例化。两者在继承体系中的职责也不同，前者偏重于实现共享，后者偏重于规格约束。
理解了这个出发点，再看纯虚函数的具体语法，你会发现很多“规矩”并不是编译器在故意为难你，而是为了实现“契约”这一目的服务的。
2. 纯虚函数的语法边界：能写什么、不能写什么、常见编译错误
2.1 纯虚函数声明中的“=0”到底是什么意思
纯虚函数的声明方式是这样的：
virtual double area() const = 0;这里= 0不是一个赋值表达式，而是C++语法里的一个特殊标记，告诉编译器“这个虚函数没有默认实现，需要在派生类中重新声明并提供实现”。所有直接或间接继承了抽象类的派生类，只要有一个纯虚函数没有实现，它自己也仍然是抽象类，仍然无法实例化。
一个容易被忽视的事实是：纯虚函数其实可以有自己的函数体。比如：
class Interface { public: virtual void cleanup() = 0 { // 可以进行一些公共清理 } };“纯虚”描述的是“必须被子类覆盖”这个约束，并不等于“完全空实现”。子类仍然必须覆盖cleanup()，但是子类的实现如果希望复用基类的公共逻辑，可以显式调用基类版本：
void CleanupImpl::cleanup() override { Interface::cleanup(); // 显式调用纯虚函数基类版本 ... }这里有个实际经验：如果纯虚函数有函数体，它必须像普通成员函数一样在类内或类外定义；如果纯虚函数只有声明没有定义，而某些代码路径又显式调用了它，链接阶段会报未定义引用。所以我的习惯是：如果不打算让纯虚函数有函数体，就直接写= 0;，别留一个空的声明在那里制造隐患。
2.2 抽象类内部可以有哪些成员
抽象类虽然不能实例化，但它作为一个类，几乎什么都能有。判断依据很简单：除了纯虚函数之外，抽象类就是一个普通类。
class Base { public: Base() = default; virtual ~Base() = default; virtual void doSomething() = 0; int commonValue() const { return value_; } void setValue(int v) { value_ = v; } private: int value_ = 0; };这段代码说明了几件事：
- 抽象类可以有构造函数。虽然不能直接
new Base()，但构造派生类对象时，基类子对象的构造仍然会调用这个构造函数。 - 抽象类可以有成员变量。这些变量会被派生类对象继承下来，成为对象内存布局的一部分。
- 抽象类可以有普通成员函数（非虚函数），这些函数在派生类中作为普通函数直接调用。
为什么允许这些？因为抽象类的目的是“定义契约，同时提供部分公共实现”。你可以在抽象类里实现一些不依赖具体类型的通用逻辑，只把需要多态分派的行为留成纯虚函数。这样既能约束接口，又不浪费公共代码。
还需要注意构造函数和析构函数中的虚函数调用问题。在构造基类子对象时，对象的动态类型还没有变成派生类；在析构基类子对象时，对象的动态类型已经变回基类。因此，在这两个阶段调用虚函数，不会发生多态分派，而是调用当前构造/析构阶段的类自己的版本。这是C++一个非常经典的知识点，笔试面试和实际调试里都容易踩到。
2.3 抽象类、普通类、接口的边界区分
C++没有专门的interface关键字，但在工程里“接口类”是一个非常常见的约定。通常指的就是：全部成员函数都是纯虚函数，且不含数据成员（或只有静态常量数据成员）的类。
class ILogger { public: virtual ~ILogger() = default; virtual void log(std::string_view msg) = 0; };这种类的约束比抽象类更严格：它不提供任何实现，纯粹定义接口形状。好处是类与实现彻底解耦，方便替换实现、打桩测试、跨模块依赖反向。
而“带默认实现的抽象类”则介于普通基类和接口类之间。它既定义契约，又预留公共实现，适合多个派生类之间存在大量共性逻辑的场景。用哪个，取决于你是想让代码“围绕接口组织”，还是想让代码“围绕复用组织”。我见过很多团队在这上面争论，其实没有绝对答案，关键要先搞清楚抽象类承担的角色到底是什么。
3. 虚表机制的内存拆解：一次虚函数调用背后发生的事情
3.1 对象里那双“看不见的手”：vptr怎么进入对象布局
理解了抽象类和纯虚函数的语义，现在进入最核心的问题：虚函数到底是怎么实现运行时多态的？答案就是虚表（vtable）和虚表指针（vptr）。
当一个类含有虚函数（包括纯虚函数）时，编译器会为这个类生成一张虚表。虚表本质上是一个地址数组，里面存放着这个类的所有虚函数入口地址。而在每个对象内部，编译器会插入一个隐藏的指针成员，这个指针叫虚表指针，它指向该类对应的虚表。
在64位平台上，一个带虚函数的对象，其大小会比不带虚函数时多出8字节，这8字节就是vptr。例如：
class Base { public: virtual void f1(); virtual void f2(); int x; };sizeof(Base)在常见64位编译器下通常是16字节：8字节的vptr加上4字节的int，加上对齐凑成16。这个vptr通常放在对象的起始位置，但也有平台放在末尾的情况。对于C++的二进制兼容性、序列化设计，这个布局知识非常关键。
3.2 虚表里到底放了什么：从声明顺序到类型信息
单继承情况下，虚表的组织相对简单。假设：
class Base { public: virtual void f1(); virtual void f2(); }; class Derived : public Base { public: void f1() override; virtual void f3(); };Base的虚表里会放&Base::f1、&Base::f2，按声明顺序排列。Derived的虚表长这样：
&Derived::f1—— 覆盖了基类的f1&Base::f2—— 没有覆盖，仍指向基类&Derived::f3—— 新增虚函数追加在后面
当调用ptr->f2()时，编译器并不知道ptr指向的具体是Base还是Derived，但它知道虚函数f2在虚表中是第2个槽位。于是实际生成的汇编逻辑是：
- 从对象地址取出vptr。
- 根据槽位偏移，从虚表中取出第2个函数地址。
- 间接跳转到该地址执行。
整个过程就是一次额外的内存读取加一次间接跳转。这也是虚函数调用比普通成员函数调用慢的直观原因之一。普通成员函数的地址在编译期就确定了，直接call即可；虚函数则必须到运行期取出地址。
纯虚函数在虚表里同样占一个槽位。如果派生类没有实现，虚表里可能放着一个指向纯虚函数调用桩的地址，一旦被调用就会触发未定义行为或断言失败。正常情况下，编译器会在实例化抽象类派生对象时拦截这类问题。
3.3 构造与销毁顺序中的“虚分派关闭时刻”
虚表不是一成不变的。在对象构造和析构过程中，对象的动态类型会发生变化。
构造一个Derived对象时，实际执行顺序是：先构造Base子对象，再构造Derived自己的部分。在Base构造函数执行期间，对象内的vptr指向的是Base的虚表，而不是Derived的虚表。这时如果Base构造函数调用了某个虚函数，它拿到的是Base的版本，不会进入Derived::f1。
等到Derived构造函数体开始执行前，编译器生成的代码会把vptr切换为Derived的虚表。此后调用虚函数才真正进入派生类版本。
析构过程的顺序正好反过来：先执行Derived析构函数体，然后析构成员，再进入Base析构函数，此时vptr已经被切回Base的虚表。
这个“逐层切换”的规则是C++标准定义的，不是编译器实现细节。所以，如果你在构造函数或析构函数里调用了虚函数，不要指望多态分派。很多诡异的崩溃和“明明调用了某个函数却不生效”的问题，根源都在这里。
知道了单继承的虚表布局，接下来必须面对多重继承。单继承只需要一个vptr，多重继承则完全是另一番局面。
4. 多重继承下的虚表偏移：那些让人崩溃的this指针修正
4.1 一个类两个vptr：多重继承的内存布局拆解
C++允许多重继承，这带来的第一个后果就是：一个对象里可能有多个vptr。
struct A { virtual void fa(); int a; }; struct B { virtual void fb(); int b; }; struct C : A, B { void fa() override; void fb() override; void fc(); int c; };C对象的内存布局大致是：
- 起始地址处是
A子对象，包含一个vptr，指向C中针对A的虚表部分。 - 之后是
B子对象，包含另一个vptr，指向C中针对B的虚表部分。 - 最后是
C自己的成员变量。
所以sizeof(C)会比想象中大不少：两个vptr被计入了，A和B各自的成员都保留了，整体还要按对齐规则补齐。
C对fa的覆盖，会被写入A子对象对应的虚表；C对fb的覆盖，则写入B子对象对应的虚表。C新增的虚函数fc通常被放入与第一个基类（也就是primary base）关联的虚表末尾。
4.2 为什么B*指向C对象时，指针要做地址偏移
多重继承最让人头痛的坑，在于指针调整。
考虑这段代码：
C c; B* pb = &c;B子对象并不在C对象的起始位置，而是位于中间某个偏移处。因此pb的实际值并不等于&c，它指向的是c内部B子对象的起始地址。这个偏移是编译期算好的，赋值时隐式完成。
问题出在虚函数调用上。假设：
C c; B* pb = &c; pb->fb();如果fb没有被C覆盖，一切正常，this就是pb，进入B::fb执行。但C覆盖了fb，编译器要从虚表里取出&C::fb并调用它。进入C::fb时，this必须是完整的C对象地址，而不是B子对象地址。于是编译器必须把pb的值减去一个偏移量，重新指回C的起始地址。
这个过程通常通过thunk（跳转包装代码）完成。thunk是一小段编译器生成的汇编代码，它的工作就是调整this指针，然后跳到真正的函数实现。这种“指针来回修正”是多继承下虚调用慢于单继承的一个原因，也是很多人调试时看到调用栈里出现奇怪符号的由来。
虚表中不仅有函数地址，Itanium C++ ABI下还记录了偏移信息，比如offset-to-top字段，它标明这个虚表相对于完整对象起始地址的偏移。dynamic_cast能正确地把B*转换为C*，依赖的就是这类信息。如果你在多重继承里发现dynamic_cast结果不符合预期，大概率是虚表偏移信息被某种错误构造破坏了。
4.3 虚继承与菱形继承：为什么C++要为此付出很大的代价
多重继承之上还有虚继承，解决的是菱形继承问题。假设D同时继承B1和B2，而B1和B2都继承自同一个Base，如果不使用虚继承，D对象里会有两份Base子对象，产生歧义。虚继承让Base在D中只有一份。
但虚继承不是免费的。为了保证这个共享副本存在，编译器需要在对象中记录虚基类的偏移，这个偏移通常也放在虚表相关区域。因此虚继承的对象布局更复杂：不是简单地按照声明顺序排列子对象，虚基类子对象往往被挪到对象靠后的位置，通过虚表里的vbase_offset来定位。
我在实际工程里对虚继承的态度是：能避则避。它带来的布局复杂性和运行期偏移计算，往往是思维负担和性能开销的双重来源。如果一个方案需要依赖菱形继承才能完成，通常可以重新审视一下接口拆分是否合理。多重继承本身并不可怕，但虚继承一定要谨慎使用。
理解虚表机制之后，析构函数的问题就会变得非常直观。上面提到的所有分派规则，在析构阶段同样适用，而析构函数一旦不是虚函数，后果比大部分人想的严重得多。
5. 虚析构函数必须掌握的释放顺序与典型内存错误
5.1 基类指针delete派生类对象：默认行为里埋着什么雷
最经典的问题长这样：
class Base { public: ~Base(); }; class Derived : public Base { std::vector<int> data_; };然后你在代码里写：
Base* p = new Derived(); delete p;如果Base的析构函数不是virtual，delete p会只按照静态类型Base*来调用析构函数。也就是说，它调用~Base()，而Derived的析构函数根本不会执行。这直接导致Derived的成员对象data_没有被析构，资源泄漏只是最轻的后果。在更复杂的情况下，这种行为属于未定义行为，可能导致崩溃或内存损坏。
为什么C++默认不允许通过基类指针正确删除派生类对象？因为普通成员函数的调用是静态绑定，析构函数也一样。编译器在delete时看到指针类型只是Base，就只调用Base的析构函数。
