C++继承机制全解析：从语法、虚函数表到菱形继承与工程实践

C++的继承，说熟悉也熟悉，说容易翻车那真是翻得稀碎。你去面试，十次有八次会被问“为什么基类析构函数要声明成virtual”；你写业务代码，也会经常在一个“到底是继承还是组合”的选择题上卡住。继承作为C++面向对象三大特性之一，也是封装继承多态里承上启下的那根轴，语法看起来就那么几行，但背后的机制、边界、代价，远比很多教程讲的要深。

这篇文章我打算把C++继承机制完整拆一遍，从最基础的语法、三种继承方式的区别，到构造析构顺序、隐藏与重写、虚函数表、抽象类，再到菱形继承、虚继承、CRTP这些进阶话题，最后再整理一批我实际开发中踩过的坑和高频面试题。不管你是刚接触C++类继承的入门读者，还是准备校招社招要刷C++八股文的同学，又或者是写了两三年业务想回头把基础夯实的老开发，这篇文章都值得你花半小时认真过一遍。

1. 继承的核心思想与语法基础

1.1 继承到底解决了什么问题

先想一个问题：你手上有两个类，Dog和Cat，它们都要吃饭、都要睡觉、都有名字，只是吃的动作和叫的声音不一样。最朴素的做法是两个类各写各的，于是“吃饭”“睡觉”“名字”这三件事的代码就复制了两遍。如果后面又来了Bird、Fish，同样的代码再复制三遍，维护起来就是灾难。

继承解决的就是这种“共性提取”和“差异扩展”的矛盾。把公共的东西抽到一个基类里，比如Animal，然后让Dog、Cat继承它。公共的属性和方法只写一份，派生类只需要专注写自己特有的部分。这背后是“is-a”的关系：一只狗确实是一种动物，一个正方形确实是一种形状，一个派生类对象天然是一个基类对象。

但这里要强调一个容易误会的点：继承的第一目的不是复用代码，而是表达类型之间的抽象关系。代码复用只是顺带的好处。如果你只是为了复用那几个函数而去强行造一个继承链，那结果往往是把类之间的耦合搞得一团糟。我见过不少项目里出现“为了用一个工具函数就把类A继承成类B”的操作，最后基类塞满了各种不相干的方法，派生类重写得面目全非——这就是把继承当工具函数库用的典型反模式。

1.2 最基本的继承语法与访问控制

C++里定义一个继承关系特别简单：

cpp复制#include <iostream>
#include <string>

class Animal {
public:
    void eat() {
        std::cout << name_ << " is eating." << std::endl;
    }

    void setName(const std::string& name) {
        name_ = name;
    }

protected:
    std::string name_;
};

class Dog : public Animal {
public:
    void bark() {
        std::cout << name_ << " says: Wang Wang!" << std::endl;
    }
};

int main() {
    Dog d;
    d.setName("Pluto");
    d.eat();   // 基类的方法，Dog直接用
    d.bark();  // 派生类自己的方法
    return 0;
}

这里class Dog : public Animal就是在告诉编译器：Dog继承Animal，继承方式是public。Dog拿到Animal里所有的成员，包括成员函数和成员变量，但是能不能访问，要看基类成员的访问级别和继承方式的组合。

访问级别有三个：public、protected、private。public谁都能碰，protected只有自己和子类能碰，private只有自己能碰。这个大家都知道，但一旦和继承方式组合起来，很多人就开始犯迷糊。

顺着这个思路，我们就得仔细说说三种继承方式的差异，这是C++继承面试里最基础也最容易答串的知识点。

2. 三种继承方式：public、protected、private怎么选

2.1 三种继承方式的可见性差异

继承方式写在类名后面，用冒号连接。它们的区别在于：基类成员在派生类里的访问级别会被“降级”成什么样。

这个表背下来是一回事，真理解是另一回事。我拆开说。

public继承是最常用、也是唯一表达“is-a”关系的方式。基类的public成员到了派生类还是public，外部使用者可以通过派生类对象直接调用这些接口。Dog是Animal，所以狗狗能调用Animal的eat()，这在语义上完全说得通。

protected继承就有点微妙了。基类的public成员到派生类这里会变成protected，也就是说外部通过派生类对象访问不到这些成员了，但派生类的子类可以。这种继承方式表达的不是“is-a”，而是“is-implemented-in-terms-of”（基于…实现）。外部不应该把一个Derived对象当Base对象用，但派生体系内部还是能看到这些接口。

private继承更极端，基类的public和protected成员在派生类里都变成private，只有当前这个派生类自己能用，它的子类再用就不行了。外部拿着这个派生类对象什么都别想访问到基类的成员。这种继承方式基本就是用来“复用实现”的，和“has-a”（组合）的语义非常接近。

为了让你看明白实际的编译差异，看这个例子：

cpp复制class Base {
public:
    void publicFunc() {}
protected:
    void protectedFunc() {}
private:
    void privateFunc() {}
};

class PubDerived : public Base {};
class ProDerived : protected Base {};
class PriDerived : private Base {};

int main() {
    PubDerived pub;
    pub.publicFunc();      // OK，public继承下publicFunc还是public

    ProDerived pro;
    // pro.publicFunc();   // 编译错误，protected继承后publicFunc变protected
    
    PriDerived pri;
    // pri.publicFunc();   // 编译错误，private继承后publicFunc变private
    return 0;
}

这段代码你可以自己跑一下，把注释去掉，看看编译器是怎么报错的。这类编译错误在IDE里虽然红得刺眼，但恰恰是理解访问控制最简单直观的路径。

2.2 实际项目里的选型原则

讲了三种继承方式的理论区别，最关键的问题来了：实际项目里到底怎么选？

先说结论：优先考虑public继承，它是唯一表达is-a语义的方式，也是绝大多数项目里唯一该出现的继承方式。 面向对象设计里的继承，默认指的就是public继承。我在不少代码评审里看到有人用protected或者private继承，问原因答不上来，只是“感觉应该这么写”。这种情况基本都可以换成组合，或者直接改成public继承，反而更清晰。

如果你发现自己需要protected继承或者private继承，先停下来想一想：你是不是真的想表达is-a关系？如果不是，那大概率你应该用组合——也就是在一个类里放一个对象成员。比如你写一个Engine类，想让Car复用它的启动逻辑，这不代表Car is-a Engine，Car is-has-a Engine才对。这时候你应该在Car里放一个Engine成员，而不是让Car : private Engine。组合的代码可读性和可维护性都比private继承好得多，后面第六章我会专门展开讲。

还有一种情况，是误把protected继承当“藏接口”的手段，觉得“我不想让外面直接看到基类的public接口，所以用protected继承”。这其实是个设计信号问题：如果基类的public接口不适合对外暴露，那这个基类本身可能就不该被外部看到，正确的做法是把基类放到细节命名空间里，或者干脆用组合。用继承方式去藏接口，只是掩耳盗铃，派生类的内部逻辑和后续维护都会更别扭。

3. 构造析构、隐藏与重写：继承的第一批坑

3.1 构造和析构的调用顺序

继承关系里的构造和析构顺序，是一个经常被忽略但无比重要的问题。很多人知道“先构造基类，再构造派生类；析构时反过来，先析构派生类，再析构基类”，但并不知道编译器具体是怎么保证这个顺序的。

构造顺序是这样的：编译器看到一个派生类对象要构造时，会先调用基类的构造函数，再初始化派生类自己的成员变量，最后执行派生类构造函数的函数体。注意这里有个细节：成员的初始化发生在基类构造完成之后、派生类构造函数的函数体执行之前。也就是说，顺序是基类构造 → 成员初始化 → 构造函数体。

析构就完全反过来：派生类析构函数体先执行 → 成员析构 → 基类析构。这个反向顺序和栈的“后进先出”逻辑是一致的，目的很明确：派生类可能用到了基类的资源，得先把自己这一层的资源清理干净，再去释放基类的。如果先析构基类，那派生类析构函数里再去访问基类成员就成访问悬空对象了。

看一个直观的例子：

cpp复制#include <iostream>

class Base {
public:
    Base()  { std::cout << "Base constructor" << std::endl; }
    ~Base() { std::cout << "Base destructor" << std::endl; }
};

class Member {
public:
    Member()  { std::cout << "Member constructor" << std::endl; }
    ~Member() { std::cout << "Member destructor" << std::endl; }
};

class Derived : public Base {
public:
    Derived()  { std::cout << "Derived constructor" << std::endl; }
    ~Derived() { std::cout << "Derived destructor" << std::endl; }
private:
    Member member_;
};

int main() {
    Derived d;
    return 0;
}

输出顺序是：

code复制Base constructor
Member constructor
Derived constructor
Derived destructor
Member destructor
Base destructor

这个顺序在实际排查问题时特别有用。比如你看到一个对象在构造时抛异常，你得知道哪一步会失败、已经构造出来的对象能不能被正常析构。C++的规则是：如果构造过程中某个环节抛异常，那么已经完成构造的成员和基类会被正常析构，但当前类的析构函数不会被调用——因为它还没构造完成。这个细节在写资源管理代码时非常重要，也是八股面试里常见的高级追问点。

3.2 函数隐藏 vs 虚函数重写

接着是继承里最容易混淆的一对概念：隐藏（hiding）和重写（overriding）。

先说重写，它指的是派生类重新实现基类里一个virtual函数，并且函数签名完全一致。重写之后，通过基类指针或引用调用这个函数时会动态绑定到派生类的版本，这是多态的基础。

隐藏则是另一回事：派生类定义了一个和基类同名的函数，不管参数列表是否相同，也不管基类那个函数是不是virtual，只要派生类里有这样一个同名函数，基类里所有同名函数就直接被“藏”起来了。这时候哪怕你想调用基类的版本，也需要用Base::func()这样的限定方式来指名道姓。

看这个代码，震撼效果拉满：

cpp复制#include <iostream>

class Base {
public:
    virtual void func(int x) {
        std::cout << "Base::func(int): " << x << std::endl;
    }
    void dummy() {
        std::cout << "Base::dummy" << std::endl;
    }
};

class Derived : public Base {
public:
    // 意图是重写Base::func(int)
    // 但没有加override，而且参数写成了double
    void func(double x) {
        std::cout << "Derived::func(double): " << x << std::endl;
    }
    void dummy() {
        std::cout << "Derived::dummy" << std::endl;
    }
};

int main() {
    Derived d;
    d.func(10);       // 调的是Derived::func(double)，10转成double，没有走多态
    // d.func(10.0)也是一样的结果
    
    Base* p = &d;
    p->func(10);      // 调的是Base::func(int)!
    
    Base* p2 = &d;
    p2->dummy();      // 调的是Base::dummy，因为dummy不是virtual
    return 0;
}

注意看，Derived::func(double)和Base::func(int)参数类型不同，在C++里这就不算重写，而是在派生类里隐藏了基类的func。所以d.func(10)不会调到基类的func(int)，而是直接调到派生类的func(double)，把10隐式转换成10.0。而用基类指针p->func(10)时，编译器看的是静态类型Base，找到的是Base::func(int)，并且因为基类这个函数是虚的，但派生类又没有重写它，于是最终调用的还是基类版本。

这里有个实用教训：任何打算做多态的函数，在派生类里必须加override关键字。 加上之后，如果签名对不上，编译器会直接报错，而不是让你在运行时“惊喜”地发现调错了版本。我见过太多莫名其妙的“多态失效”问题，最后都是因为少写了override，或者参数类型悄悄变了。

另外，隐藏不仅发生在虚函数之间，普通成员函数同名也会隐藏。你在派生类里写了一个dummy()，基类的dummy()在d这个对象上就直接调不到了。想调用基类的版本，必须写成d.Base::dummy()。这种隐藏机制是C++里一个历史遗留设计，很多其他语言没有，所以一定要记住。

3.3 派生类构造时给基类传参

如果基类没有默认构造函数，那么派生类的构造函数必须在初始化列表里显式调用基类的某个构造函数。这个语法是这样的：

cpp复制class Base {
public:
    Base(int id) : id_(id) {}
private:
    int id_;
};

class Derived : public Base {
public:
    // 必须在初始化列表里给Base的构造函数传参
    Derived(int id, const std::string& name) 
        : Base(id), name_(name) {}
private:
    std::string name_;
};

这里有一个非常容易踩的坑：如果你在Derived的构造函数函数体里给基类成员赋值，那是在基类已经构造完成之后才做的，根本改变不了基类成员的初始化方式。 基类成员如果在基类构造函数里是const或者是引用，那就只能在基类的初始化列表里初始化，派生类这边一点办法都没有。

我强烈建议所有C++开发者在写派生类构造函数时，养成“先列出基类构造，再列出成员初始化”的习惯。而且要注意顺序问题：编译器不会按照你初始化列表里书写的顺序来初始化，而是按照声明顺序来初始化。如果基类构造写的顺序不对，可能会产生warning，在某些编译选项下直接报错。

4. 多态机制、虚函数表与接口设计

4.1 虚函数与动态绑定原理

多态的实现机制，是C++面试绕不开的核心。在C++里，多态靠的是虚函数。你声明一个函数为virtual，编译器就会为这个类生成一张虚函数表（vtable），每个对象里额外带一个虚函数表指针（vptr），指向这个类的虚函数表。

当通过基类指针或引用调用虚函数时，程序不会在编译期决定调用哪个函数，而是在运行时根据对象的实际类型去查虚函数表，找到对应函数的地址再调用。这就是动态绑定。

说的直白点：Base* p虽然静态类型是Base*，但它指向的对象可能是Base，也可能是Derived。虚函数表就相当于给每个类的函数地址做了个索引，调用的时候先看对象里存的vptr指向哪张表，再查表跳转。

cpp复制#include <iostream>

class Shape {
public:
    virtual void draw() const {
        std::cout << "Drawing Shape" << std::endl;
    }
    virtual ~Shape() {}
};

class Circle : public Shape {
public:
    void draw() const override {
        std::cout << "Drawing Circle" << std::endl;
    }
};

void render(const Shape& s) {
    s.draw();  // 运行时才知道调的是谁
}

int main() {
    Shape s;
    Circle c;
    render(s);  // Shape::draw
    render(c);  // Circle::draw
    return 0;
}

这段代码就是多态的典型展示。render接收一个Shape的引用，具体调用哪个draw是运行时决定的。这就是多态的意义：你写代码时可以面向抽象基类编程，具体的实现由子类各自完成，后续增加新形状时，render函数完全不用改。

理解虚函数表原理还有个直接好处：类的内存布局。一个带虚函数的类，对象里会多一个vptr指针（通常占用8个字节），这会影响对象大小、拷贝行为和内存对齐。性能敏感的程序里，小对象频繁拷贝时，这个额外指针的开销是被真实感受到的。这也是为什么有些高性能场景宁可放弃多态，改用模板或CRTP来换取零抽象开销。

4.2 为什么基类析构要virtual

这是C++面试里出现频率最高的一个问题，没有之一。答案说来也简单：如果你通过基类指针去delete一个派生类对象，而基类析构函数不是virtual，那么程序只会调用基类的析构函数，派生类的析构函数不会被执行，派生类持有的资源就不会被释放。

这个行为在C++标准里是未定义行为，但在实际实现中，通常的结果就是“只析构了基类的那部分，派生类那部分的内存和资源漏了”。听起来很抽象，看代码就懂了：

cpp复制#include <iostream>
#include <memory>

class Base {
public:
    Base() { std::cout << "Base created" << std::endl; }
    ~Base() { std::cout << "Base destroyed" << std::endl; }
};

class Derived : public Base {
public:
    Derived() { 
        buf_ = new char[1024];
        std::cout << "Derived created, buffer allocated" << std::endl; 
    }
    ~Derived() {
        delete[] buf_;
        std::cout << "Derived destroyed, buffer freed" << std::endl;
    }
private:
    char* buf_;
};

int main() {
    Base* p = new Derived();
    delete p;  // 只调用Base::~Base()，Derived的析构函数没被调用！
    return 0;
}

运行这段代码，输出里只有Base destroyed，永远不会出现Derived destroyed。那个1024字节的buffer就泄漏了。这还只是泄漏，如果派生类析构函数里有更复杂的资源释放逻辑，比如释放互斥锁、关闭文件、归还网络连接，那后果更严重。

解决办法也简单：把基类的析构函数声明为virtual。只要基类析构是virtual，通过基类指针delete派生类对象时，就会根据虚函数表动态找到派生类的析构函数，先执行派生类析构函数体，再按析构顺序逐层调用基类析构。

这里有个实际建议：任何打算被继承的基类，都要带一个virtual析构函数。 哪怕基类析构函数什么都不干，也得加virtual。很多书上说“只有当要通过基类指针delete派生类对象时才需要”，但现实中你很难保证基类指针永远不会被这样用，所以干脆默认都加。

顺便提一嘴，如果你是在设计一个不希望被继承的类，可以在类后面加final关键字，比如class Base final { ... };，这样编译器会直接禁止继承，从源头上把问题解决掉。

4.3 纯虚函数与抽象类

当你在基类里写一个纯虚函数，比如：

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

这个= 0的意思是这个虚函数没有默认实现，类Shape变成了抽象类。抽象类不能直接实例化，你不能写Shape s;。如果你继承它，必须在派生类里实现所有纯虚函数，否则这个派生类仍然是抽象类，照样不能实例化。

纯虚函数的意义在于定义接口契约。Shape只规定“你有draw的能力”，但具体怎么画，每个派生类自己说了算。这在实际项目里非常有用：你可以把系统的扩展点定义为抽象基类，然后由不同团队、不同模块去实现，只要他们实现了所有纯虚函数，系统就能无缝接入。

还有一类抽象类叫“纯接口类”，所有成员函数都是纯虚函数，并且通常有一个virtual析构函数，没有数据成员。这种设计在大型C++项目里很常见，它把接口和实现完全解耦。你可以随意替换实现而不影响调用方的代码。

要注意的是，纯虚函数也可以有函数体，这在C++里是允许的，派生类可以显式调用Base::method()。这个特性偶尔有人用来做公共逻辑的兜底，但用得很少，属于“知道有这么个事”的程度就够了。

5. 菱形继承、虚继承与复杂体系的设计代价

5.1 菱形继承的二义性

C++允许一个类有多个直接基类，这叫多继承。多继承本身不是洪水猛兽，但它有个著名的坑——菱形继承。

菱形继承的结构是这样的：A是根基类，B和C都继承自A，然后D同时继承B和C。这就形成了一个菱形的继承结构。问题来了：D的对象里到底有几份A的成员？按默认规则，会有两份——B里一份A的子对象，C里一份A的子对象。D里需要访问A的成员时，编译器分不清你要访问哪一份，直接报二义性错误。

cpp复制#include <iostream>

class A {
public:
    int value;
};

class B : public A {};
class C : public A {};
class D : public B, public C {};

int main() {
    D d;
    // d.value = 10;   // 编译错误：二义性，value在两份A子对象里都有
    d.B::value = 10;   // 显式指定走B里的A
    d.C::value = 20;   // 显式指定走C里的A
    std::cout << d.B::value << ", " << d.C::value << std::endl; // 10, 20
    return 0;
}

注意看，d.B::value和d.C::value是两个不同的变量，它们各自属于B和C里各自包含的A子对象。如果你期望的是“D里只有一份value”，那默认的菱形继承实现方式就完全不符合预期。

这种结构还会引发更隐蔽的问题：对象布局变复杂，类型转换容易出错，甚至同一个A对象的地址在D里通过B和C分别转换可能会得到不同的指针值。这些都是多继承里常见的“埋雷点”。

5.2 虚继承的机制与开销

解决菱形继承重复子对象问题的方法是虚继承。声明继承关系时加上virtual关键字：

cpp复制class A {
public:
    int value;
};

class B : virtual public A {};
class C : virtual public A {};
class D : public B, public C {};

这样，无论B、C怎么继承A，D里都只会保有一份A的子对象。d.value = 10这里就不再有二义性了。

虚继承的底层实现和普通继承不同。编译器需要额外引入某种间接寻址机制（具体实现可能是vbptr虚基类表指针，也可能是其他偏移方式），来定位唯一的虚基类子对象。这意味着两件事：一是对象体积会变大，因为每个虚继承的类都要额外存放虚基类相关的指针或偏移信息；二是访问虚基类成员的效率相比普通成员会略低，因为多了一次间接寻址。

实际项目的建议是：尽量避免设计出菱形继承结构，尤其是深层继承加多继承的组合。 如果你觉得自己需要菱形继承，先停下来重新审视设计，是不是抽象层次出了问题。虚继承是C++为了兼容复杂继承需求提供的一件工具，但使用它意味着你在传递一个“这个继承体系很复杂”的信号，后续每个继承它的人都得跟着支付理解和维护成本。

如果确实绕不开菱形继承，那就把虚基类的构造函数初始化统一管好：虚基类必须由最派生类负责初始化，中间层类的初始化列表里对虚基类的初始化会被忽略。这个规则在学习虚继承时很容易忽略，也是实际编译错误里比较磨人的一个点。我建议你在一张纸上画清楚继承关系图，标好每一层的构造责任再动手写代码。

6. 通用设计原则：组合优先、CRTP和工程建议

6.1 组合优于继承

聊到这块，就要讲讲那句著名的设计原则：组合优于继承。 用组合的意思是说，你可以在类里放一个对象作为成员，通过它来复用功能，而不是用继承。为什么组合常常比继承更好？

第一，耦合更松。继承意味着派生类能看到基类的protected成员，基类一改动，所有派生类都可能受影响。组合只在类内部持有另一个类的对象，外部接口更加稳定。

第二，没有继承体系的“形状”约束。继承强迫你去符合is-a的关系，而很多代码复用的场景根本不存在is-a关系。一个Car里面放一个Engine，明显就是“有一个”而不是“是一个”，用组合语义上更自然。

第三，行为更加灵活。继承的复用发生在编译期，绑定是静态的；组合的复用发生在运行时，你可以随时替换内部的实现对象。比如给Car换一个更高性能的Engine，用组合就是改一下构造函数传参的事，用继承就得再定义一个SportsCar类。

在实际项目里，我的经验是：先问自己“这个新类真的是一种旧类吗？”如果是，用继承；如果不是，90%的情况用组合。我后来做代码评审时，看到有人写继承，第一个问题永远是“这个is-a关系成立吗？”，十次里能有三四次对方答不上来或者支支吾吾，这时候改成组合基本都更清爽。

6.2 CRTP：编译期多态的继承技巧

说到继承和多态，CRTP是绕不过去的一个话题。CRTP全称是Curiously Recurring Template Pattern（奇异递归模板模式），核心思想是：在基类模板里，把派生类作为模板参数传进去。

cpp复制template <typename Derived>
class Base {
public:
    void interface() {
        static_cast<Derived*>(this)->implementation();
    }
};

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

这里的巧妙之处在于，Base<Derived>是基类，但基类在编译期就知道自己会跟哪个派生类配合。interface()里的static_cast<Derived*>(this)把基类指针转成派生类指针，然后调用派生类的方法。整个过程没有虚函数，没有虚函数表，没有运行时开销——这是编译期多态。

CRTP的实际用途很多，比如给某个类自动扩展出比较操作符、序列化函数、工厂方法等。它的优势是效率和类型安全，代价是可读性稍差、模板代码上手门槛高。在实际项目中，如果性能敏感、对象特别小、不适合加虚函数指针，CRTP就可以顶上。但如果你还在学习阶段，我建议先把它和普通继承区分开理解，知道它是“用模板在编译期把基类和派生类绑死”的技巧就够了。

6.3 几个实际工程建议

很多刚接触C++类继承的同学，代码写起来特别奔放，继承层次一层套一层，最后变成一团乱麻。我根据自己的项目经验，整理几条硬性建议：

第一，继承层次控制在三层以内。 超过三层，代码的可读性和可维护性会急剧下降。你在上层改一个函数签名，下层的实现可能全都得跟着动。如果一个类体系超过三层，我会考虑是不是抽象方式出了问题。

第二，善用override和final。 在派生类里重写虚函数必须加override，编译器能帮你检查签名是否一致。final可以阻止类被继续继承，也可以阻止虚函数被继续重写，在想要稳定接口的地方大胆用。

第三，基类的析构函数默认就写成virtual。 这是我前面强调过的，宁可多写也不要不写。尤其当你正在写一个准备被别人继承的基类，这点几乎是必须的。

第四，谨慎使用多继承。 多继承不是不能用，但用它之前先想清楚有没有更简单的替代方案。纯接口类组合多继承是相对安全的用法，但让多个具体类同时成为基类，就要特别小心菱形继承和成员二义性的问题。

第五，能用std::unique_ptr和std::shared_ptr管理继承体系里的对象时，别裸用raw pointer。 智能指针配合多态使用是C++现代实践的标配。裸指针管理继承对象最大的隐患就是忘记delete或者重复delete，智能指针可以从源头规避。

7. 高频面试题与易错点速查

7.1 常见问题问答

这些是我自己在面试别人和准备面试时都觉得值得收藏的问题，分享给大家。

问：为什么基类析构函数要声明为virtual？

答：这样通过基类指针delete派生类对象时，才会根据实际对象类型动态调用派生类的析构函数，避免派生类资源泄漏。否则派生类析构函数不会被调用。

问：构造函数和析构函数里能调用虚函数吗？

答：在构造函数和析构函数里调用虚函数，不会发生动态绑定。因为构造时虚函数表还没有完全设置好，析构时虚函数表可能已经部分失效了。所以这两个阶段里的虚函数调用，实际上调用的是当前正在构造/析构的那个类自身版本，而不是最终派生类的版本。

问：重写（override）和重载（overload）有什么区别？

答：重载是同一个类里函数名相同但参数列表不同，编译期就确定调用哪个版本。重写是派生类对基类虚函数的重新实现，函数签名完全一致，运行期动态绑定。还有一个“隐藏”的概念，派生类定义同名函数会把基类的同名函数藏起来，这个和重写、重载都不同，特别容易混。

问：抽象类能作为函数参数吗？

答：可以，但要用指针或引用。抽象类不能实例化，所以不能传值，但可以传指针或引用，这样就能实现运行时多态。返回值也是一样，应该返回指针或引用，不该返回抽象类对象本身。

问：什么是切片问题？

答：把一个派生类对象赋值给基类对象时，派生类特有的部分会被“切掉”，只保留基类部分。这就是切片。Base b = derived;会调用基类的拷贝构造函数，derived里派生类的数据全部丢失。避免方法是使用指针或引用。

7.2 自查清单

技术面试前可以拿这份清单自查一遍。每一条背后都有文章里对应的内容，答不上来的回去翻一翻。

• 能说出public/protected/private继承下，基类public/protected/private成员在派生类里的访问级别。
• 能默写构造和析构的调用顺序，并解释为什么。
• 知道override关键字是干什么的，知道隐藏和重写的区别。
• 能画出带虚函数的类的内存布局，说出vptr存在哪个位置。
• 知道为什么基类析构函数要virtual，能讲清楚不virtual的后果。
• 能写出一个纯虚函数，解释抽象类为什么不能实例化。
• 知道菱形继承的二义性是怎么产生的，虚继承怎么解决，代价是什么。
• 知道override和final的用法，能在实际代码里用对。
• 能解释组合优于继承是为什么，举一个该用组合却被写成继承的例子。

这些内容看起来多，但核心脉络其实就一句话：继承是用来表达类型关系的机制，多态是配合继承在运行期做动态分发的手段，理解了虚函数表和对象布局，很多坑都是可以提前预见的。我写了这么多年C++，最深的感受是：继承本身不难，难的是知道什么时候不该用它。把基础打扎实，写码的时候多用override、多问自己是不是真的is-a，大型项目里能省下的眼泪绝对比想象中多。

最后分享一个小技巧：在Visual Studio Code里配置C/C++环境时，记得把编译标准设置成c++17或更高，然后打开-Wall -Wextra警告选项。继承相关的很多坑，比如隐藏、签名不匹配，编译器都会给你警告，别把警告当耳边风处理，一个个看懂、改完，你的编码习惯会好很多。