写C++这么久，我印象最深的不是模板元编程有多巧妙，也不是哪个库性能又提升了多少，而是项目里一条藏了两天的内存泄漏线索。最后定位到的问题居然是基类析构函数忘了加virtual，析构一个派生类对象时只走了基类析构路径，子类里申请的资源全漏了。这类问题在面试里也常出现，问的就是虚析构函数、纯虚函数、抽象类、override和final这些面向对象关键字。这篇 C++ 传记，不聊语言发明史，只聊我们写业务代码时最容易踩的几个面向对象坑，把这几个概念串起来讲透。

1. 虚析构函数：一旦继承，就要考虑怎么销毁

1.1 一个让人头疼的内存泄漏例子

先看一个非常经典的错误写法。假设我们有一个Base类，里面正常管理了资源，但析构函数没有加virtual，然后派生出Derived，派生类里又额外申请了一份资源：

#include <iostream> class Base { public: Base() { std::cout << "Base constructed\n"; } ~Base() { std::cout << "Base destroyed\n"; } }; class Derived : public Base { public: Derived() { std::cout << "Derived constructed\n"; m_data = new int[100]; } ~Derived() { delete[] m_data; std::cout << "Derived destroyed\n"; } private: int* m_data; }; int main() { Base* p = new Derived; delete p; }

这段代码的输出很有意思：

Base constructed Derived constructed Base destroyed

注意，delete p这一行，根本没有调用Derived的析构函数。m_data申请的内存就这样静悄悄漏掉了。更让人头疼的是，代码运行起来不一定立刻崩溃。除非你恰好检测到了内存增长异常，否则它可能潜伏在程序里好几个月。

为什么会出现这种问题？因为Base* p的静态类型是Base*，而它实际指向的对象动态类型是Derived。当编译器看到delete p时，它需要决定调用哪个析构函数。如果Base的析构函数不是虚函数，编译器会按静态类型调用：Base::~Base()。它不会理会指针背后那个对象的真实类型。这就是经典的多态失效：同样的delete语句，面对不同类型对象时应该走不同的析构逻辑，但语言层面没有把这个机制接通。

1.2 虚析构函数到底在做什么

把Base的析构函数声明为虚函数，问题就解决了：

class Base { public: virtual ~Base() { std::cout << "Base destroyed\n"; } };

再运行刚才那段main，输出变成：

Base constructed Derived constructed Derived destroyed Base destroyed

这下析构顺序就对了：先执行派生类的析构函数体，然后自动调用基类的析构函数，一层一层往祖先方向清理。C++ 里对象的析构顺序本来就是这样设计的：派生类先析构，基类后析构。所以只要最外层的析构入口走对了，整个链条不会断。

虚析构实现的底层机制，其实是虚函数表。类里只要有虚函数，对象内部就会多一个隐藏的虚指针，指向该类型的虚函数表。析构函数一旦声明为虚函数，也会放进这张表里。删除Base*指针时，程序先去查虚函数表，找到实际类型对应的析构函数再调用。这个查找是运行时行为，所以不管指针指向Derived还是更深的子类，都能正确找到对应的析构入口。你可以把它理解成一个“出口登记表”：每个人离开的时候，先到登记表上查自己真正该走的那扇门，而不是稀里糊涂跟着大厅出口标志走出去。

这里有一个细节值得说：delete一个对象其实做了两件事，先调用析构函数，再调用operator delete释放内存。所以如果析构函数是虚的，连带着operator delete的调用也会经过虚机制，确保内存释放匹配正确的类型。这就是为什么千万别在析构函数里手动调用delete this配合不虚的析构函数玩花活，很容易在内存释放阶段双倍释放。

1.3 什么时候可以偷懒不写

写虚析构函数当然有代价。一是对象体积会变大，因为要多存一个虚指针；二是调用析构函数时多一层间接跳转，性能上比直接调用要慢一点点。但绝大多数业务场景里，这点开销可以忽略不计。真正的问题在于：不写虚析构的风险比那点性能开销大得多。

那么什么时候可以真的不写？我自己的实践是下面几种情况：

• 类根本没有被继承，也不打算被继承。这种情况下没有“通过基类指针删除派生类对象”的问题。
• 类的继承关系很明确，但你保证所有对象都是以值的方式存储和使用。比如栈上对象Derived d，生命周期结束自然调用Derived的析构，不通过Base*删除。
• 你给类加上了final，从语言层面禁止它再作为基类使用。这种情况下不写虚析构也安全，反正不会有子类。

不过面试和项目评审里，我建议你记住一条更稳妥的原则：如果一个类里有虚函数，那它就应该有虚析构函数。反过来也成立，如果一个类要被多态使用，不管里面有没有业务虚函数，析构函数都建议写成虚的。这条原则虽然有点一刀切，但能挡住绝大多数内存释放问题，尤其是代码在别人手里被扩展的时候。

提示：在 C++11 及以后，virtual ~Base() = default;是一种非常干净的写法。它明确表达“我有虚析构，但析构逻辑用默认的”，也保留了继承链上的多态释放能力。

2. 纯虚函数与抽象类：从“能做什么”到“必须做什么”

2.1 纯虚函数的语法和语义

在类里声明虚函数时，末尾写上= 0，这个函数就是纯虚函数：

class Shape { public: virtual double area() const = 0; };

= 0不是在说“这个函数等于零”，而是语言层面的一个纯虚说明符。它告诉编译器：这个函数在当前类里不提供实现，或者不打算让当前类提供有效实现，所有能实例化的派生类都必须覆盖它。

一个类里只要有一个纯虚函数（或者从基类继承了没有覆盖的纯虚函数），这个类就变成了抽象类。抽象类有几个硬性限制：

• 不能直接实例化：Shape s;是编译错误。
• 可以声明它的指针和引用：Shape* p;没问题。
• 派生类如果还没有覆盖所有纯虚函数，那它仍然是抽象类，不能创建对象。

这种设计非常符合日常语义。比如“形状”这个概念本身是空泛的，你没法画一个“形状”出来，你只能画圆、画矩形、画三角形。所以Shape应当是一个抽象概念，具体行为交给派生类。

纯虚函数可以有实现吗？可以。你完全可以在类外给纯虚函数写一个函数体：

class Shape { public: virtual double area() const = 0; }; double Shape::area() const { return 0.0; }

但要注意，即使你写了这个实现，Shape仍然是抽象类，仍然无法直接实例化。派生类依然必须实现area，才能创建对象。那这个函数体还能被调用吗？能。派生类可以直接用Shape::area()当默认实现，只是自己不写默认逻辑而已。这种方式适合某些已经有约定俗成默认行为的接口，不过实际项目中不多见。

2.2 抽象类怎么影响你的工程架构

从工程角度看，纯虚函数最大的价值是在代码里画出一条“契约线”。抽象类把“要做什么”和“怎么做”分开，调用方只依赖抽象接口，不依赖具体实现，这样依赖关系就反转了。

举个例子，假设你写一个日志模块。最偷懒的方式是直接在一个类里写死日志输出到控制台。可项目后面要加文件日志、网络日志，你发现所有日志相关代码都要改。更合理的做法是先定义接口：

class ILogger { public: virtual ~ILogger() = default; virtual void LogInfo(const std::string& msg) = 0; virtual void LogError(const std::string& msg) = 0; };

然后业务代码里只持有ILogger*或者ILogger&，具体是控制台日志还是文件日志，由启动时注入进去。这个设计就是典型的依赖倒置：高层模块不依赖底层模块，两者都依赖抽象接口。插件化架构、测试替身、策略模式、观察者模式，底层几乎都是这个东西。

我见过不少刚接触接口设计的同学，会在抽象类里塞很多空实现，或者把所有函数都写成纯虚函数。经验上，纯虚函数是用来定义“外部必须提供”的能力，不是用来把所有成员函数都掏空。如果某个函数当前类和派生类都可以有合理的默认实现，那它更适合做成普通虚函数；只有“缺了这个实现类就没法正常工作”的关键行为，才应该做成纯虚函数。

2.3 抽象类不是空壳：构造、析构和成员方法

抽象类虽然不能实例化，但照样可以有构造函数、析构函数、普通成员函数和成员变量。构造函数的主要用途是初始化抽象类自己的状态。比如一个抽象类保存了名称，派生类构造时必须把这个状态传上来：

class Shape { public: Shape(const std::string& name) : m_name(name) {} virtual ~Shape() = default; const std::string& Name() const { return m_name; } virtual double area() const = 0; private: std::string m_name; }; class Circle : public Shape { public: Circle(double r) : Shape("Circle"), m_radius(r) {} double area() const override { return 3.14159265 * m_radius * m_radius; } private: double m_radius; };

还有一点，抽象类的析构函数同样推荐声明为虚函数。原因和上一节完全一样：你很可能通过Shape*指针管理一个Circle对象，析构入口必须能正确落到Circle的析构函数上。

抽象类的析构函数也可以是纯虚的，这是很多资料里一笔带过、但实际一写就出错的点，单独拿出来说更清楚。

2.4 纯虚析构函数的坑

有时你会遇到一种场景：想定义一个抽象类，但里面并没有其他适合写成纯虚函数的接口方法。这时候有人会把析构函数写成纯虚的，让类变成抽象类：

class AbstractOnly { public: virtual ~AbstractOnly() = 0; };

如果代码写到这就停了，链接阶段一定会报错，错误信息类似undefined reference to AbstractOnly::~AbstractOnly()。原因是纯虚析构函数和普通纯虚函数不一样：任何派生类对象析构时，都会隐式调用基类的析构函数。虽然你把这个析构函数声明成了纯虚，但只要派生类对象结束生命周期，编译器仍然会计入这次基类析构调用，它需要一个实现地址。普通纯虚函数可以没有实现，因为没人会在子类里主动调用；但析构函数不是一个“主动调用”的接口，它是整个析构流程里的固定环节。

解决办法是必须在类外提供定义：

AbstractOnly::~AbstractOnly() {}

这样类既保持抽象，析构链也能正常走完。不过说实话，纯虚析构函数在实际项目里很少出现，它更多是为了“占一个纯虚函数名额”而存在。我从实践角度不太推荐这种写法，因为它容易让读者困惑：析构函数明明有实现，为什么写着= 0？如果只是想禁止类被实例化，更直白的方案是把析构函数设为protected：

class AbstractOnly { protected: ~AbstractOnly() {} };

这样从外部也没法直接delete这种类型，但派生类可以正常析构整条链。当然，它也有局限：不能通过基类指针随意delete，得想清楚所有权模型。总之，纯虚析构是能用的语法，但遇到它时多留个心眼。

3. final 与 override：让继承体系长出牙齿

3.1 override：虚函数重写的契约检查

在 C++11 之前，虚函数重写出错是非常阴险的：你写了一个派生类函数，以为它覆盖了基类虚函数，结果因为参数类型不一样、少了const、返回值不匹配，编译器把它当成了一个全新的成员函数。程序运行起来，多态调用根本不进你的函数。这种问题不报错，但行为完全错位，调试成本极高。

override解决的就是这个问题。在派生类的函数签名末尾写上override，编译器会检查它是否真的在覆盖一个基类虚函数。如果匹配不上，直接编译失败。

class Base { public: virtual void show() const; }; class Derived : public Base { public: void show() const override; // 合法 void show() override; // 编译错误：基类里没有 const 版本 };

这个特性特别适合在重构时使用。比如基类某个虚函数改了参数类型，所有派生类中标记了override的函数都会被编译器标记出来，帮你把整个继承体系的一致性检查一遍。没写override的时候，基类改动可能会让很多派生类函数悄悄“脱钩”，你很难发现。

还有一个细节值得提：析构函数也可以标记override。如果一个派生类的析构函数写了override，而基类析构不是虚函数，编译器会报错。所以对接口类来说，在派生类里写~Derived() override;是一个很好的自检手段，可以有效防止基类漏写虚析构。

override的另一个隐藏价值在于代码阅读。看到它，别人就知道这个函数不是普通成员函数，而是有意覆盖基类虚函数的。团队协作时，这行关键字就是一张契约凭证。

3.2 final：把继承和重写的闸门关掉

final可以放在类名后面，也可以放在虚函数签名后面，语义各有不同。

放在类名后面，表示这个类不能再被继承：

class Derived final : public Base { // ... }; class Grand : public Derived { // 编译错误 };

放在虚函数后面，表示这个虚函数到这里就是终点了，更下级的派生类不能再次覆盖：

class Base { public: virtual void step() {} virtual void final_step() final {} }; class Derived : public Base { void final_step() override {} // 编译错误：final_step 是 final 的 };

在实际工程里，final最常见的用途有两个。第一，在较深的继承层级中，叶子类明确不再被继承，避免后来者写出越来越复杂的类派生链。第二，给编译器提供去虚拟化的线索。一个类是final的时候，通过该类型指针调用虚函数，编译器有理由把这个虚调用直接变成普通调用，因为编译器知道不会再有子类改变它的虚函数表。这个优化有时候很可观，尤其是在关键渲染路径、游戏循环这类对性能敏感的地方，final比空着不写更有价值。

3.3 什么时候用 override，什么时候用 final

这两者不是二选一的互斥关系，而是两种不同阶段的护栏。

• override是关于“当前这个函数确实覆盖了基类虚函数”的编译期检查。只要你在派生类里写虚函数覆盖，就应该尽量带上它。C++ 编码规范里，这条已经算是主流共识了。
• final是关于“后续不该再改”的表达。当你确定某个虚函数不应该被更深的子类修改时，就加final。当确定某个类不应该再被继承时，直接给类加final。
• 那一个函数能同时写override final吗？能。void f() override final;的意思是：这个函数覆盖了基类虚函数，同时它在这条链上封死了后续覆盖。这种情况常见于多层继承体系中的中间层，它自己重写了一个接口，同时不让后来的子类再动这个行为。

实际项目里我的习惯是：接口类只声明纯虚函数，具体实现类的公开行为一旦定死，能加final的地方就加。这样类层次清晰，编译器也能拿到更多优化空间。但是也别为了炫技到处加final，如果类的用途本来就是作为扩展点，过早final等于堵死了别人正常扩展的路。

4. 综合案例：一个基于抽象类的图形系统

4.1 需求与设计

前面这些概念单独看都简单，但它们组合起来才能真正发挥威力。下面用一个完整的图形系统来串联一遍。需求很简单：能表达圆形和矩形，能计算面积，能打印信息，并且容器中保存的是抽象基类指针。

设计要点：

• Shape作为抽象基类，定义纯虚函数area()和print()。
• Shape的析构函数声明为虚，保证通过Shape*删除派生类对象时析构链完整。
• Circle和Rectangle作为具体实现类。
• 因为两种形状都是叶子类，加上final标记。
• 容器使用std::vector<std::unique_ptr<Shape>>，让智能指针代替我们管理内存。

4.2 代码实现

#include <iostream> #include <memory> #include <vector> class Shape { public: virtual ~Shape() = default; virtual double area() const = 0; virtual void print(std::ostream& os) const = 0; }; class Circle final : public Shape { public: explicit Circle(double radius) : m_radius(radius) {} double area() const override { return 3.14159265358979323846 * m_radius * m_radius; } void print(std::ostream& os) const override { os << "Circle(radius=" << m_radius << ", area=" << area() << ")"; } private: double m_radius; }; class Rectangle final : public Shape { public: Rectangle(double width, double height) : m_width(width), m_height(height) {} double area() const override { return m_width * m_height; } void print(std::ostream& os) const override { os << "Rectangle(width=" << m_width << ", height=" << m_height << ", area=" << area() << ")"; } private: double m_width; double m_height; }; int main() { std::vector<std::unique_ptr<Shape>> shapes; shapes.emplace_back(std::make_unique<Circle>(2.0)); shapes.emplace_back(std::make_unique<Rectangle>(3.0, 4.0)); for (const auto& shape : shapes) { shape->print(std::cout); std::cout << "\n"; } }

这段代码里，抽象类、虚析构函数、纯虚函数、override、final全部用上了。运行结果：

Circle(radius=2, area=12.5664) Rectangle(width=3, height=4, area=12)

你可能觉得这个案例有点基础，但它把一个关键点体现得很清楚：shapes容器里存的是unique_ptr<Shape>，也就是抽象基类的指针。没有虚析构，容器销毁时只会释放Shape部分，派生类里的资源就漏了。有了虚析构，容器销毁时每个元素都会先走实际类型的析构逻辑，再走基类析构逻辑，整条链是完整闭合的。这正是现代 C++ 里“智能指针 + 抽象基类 + 虚析构”的标准组合。

4.3 运行结果与内存验证

如果你把Shape的析构函数去掉virtual，这段代码依然能编译、能运行，甚至输出看起来一模一样。内存泄漏不会在输出里直接显示出来，这也是为什么很多新人认识不到虚析构的重要性。要验证是否正确析构，比较简单的方式是在析构函数里打印日志，或者用一个静态计数器统计构造和析构次数。构造了三个对象，析构了三个对象，才说明析构链是完整的。

真正跑大型项目时，可以用内存检测工具观察，但我个人的经验是：别依赖工具，先用设计层面的习惯把坑填平。看到抽象基类，第一反应就是确认析构是否是虚的；看到派生类重写虚函数，第一反应就是写上override。这套习惯比事后检测可靠得多。

5. 常见问题排查与避坑指南

5.1 编译期报错的速查

5.2 运行期崩溃的典型场景

运行期最常见的两类问题，一类是对象析构不完整导致资源泄漏，另一类是析构顺序异常导致崩溃。比如析构函数里访问了已经被释放的成员，或者派生类析构函数已经删除了某个资源，而基类析构函数又尝试访问一次。遇到这种问题，先画一张继承链，确认整个析构顺序。C++ 的析构顺序是：派生类析构函数体执行完，再依次调用基类析构函数，直到最顶层。脑内跑一遍顺序，大部分崩溃原因都能定位。

还有一类问题来自析构函数内部调用虚函数。也许有人告诉过你“析构函数里不要调用虚函数”，这句话说有道理但不够精确。在析构函数里调用虚函数，调用会解析到当前这个类自己的实现，而不是更下层的派生类实现。因为当析构进入基类阶段时，派生类部分已经被销毁，虚函数表也已经变成了基类版本。如果你期望调用到派生类的实现，结果必然是落空。所以不要在基类析构函数里指望虚调用帮你完成“再多清理一步”的意图，那一步应该在派生类自己的析构函数里做。

5.3 一点个人经验

把虚析构、纯虚函数、抽象类、override、final串起来看，C++ 其实给开发者提供了很多“自我约束工具”。abstract约束了你必须实现什么，override约束了你不能抄错签名，final约束了后面的人不能随便破坏既定逻辑，虚析构则保证了多态销毁时不会漏掉任何一层。这几个特性单独都不难，难的是把它们当成一套规则体系来使用。我个人踩过几次坑之后，养成了一套固定写法：抽象基类的析构一律virtual ... = default；所有覆盖方法一律加override；不希望被继续扩展的叶类一律加final。这套写法换了好几个项目都很稳，也建议你试试。