C++函数重写详解：从虚函数、动态绑定到多态继承的底层原理

写 C++ 这么多年，很多刚入门的同学问得最多的一个问题就是：函数重写到底是怎么一回事？为什么我写了同名函数，有时候调用的是基类的，有时候又是派生类的？其实这个问题背后牵扯到虚函数、动态绑定、继承设计，一旦理清楚了，你对整个 C++ 面向对象体系的理解会上一个大台阶。这篇文章不打算写教科书式的长篇大论，而是想用我平时排查问题、做代码重构时积累下来的经验，把函数重写的原理、写法和踩坑点一次讲透。适合刚学完类的继承、想看明白多态背后机制的同学，也适合准备 C++ 面试、想系统梳理一遍重写相关考点的开发者。

1. 函数重写到底解决什么问题

1.1 没有重写机制时的尴尬

想象你现在要做一个动物园管理系统，需要让不同动物发出叫声。最原始的做法是这样：每种动物一个类，各自实现自己的 speak，然后在处理的时候用一堆 if 判断。

cpp复制class Dog {
public:
    void speak() { cout << "Woof" << endl; }
};

class Cat {
public:
    void speak() { cout << "Meow" << endl; }
};

void makeAnimalSpeak(int type) {
    if (type == 0) {
        Dog d;
        d.speak();
    } else if (type == 1) {
        Cat c;
        c.speak();
    }
}

问题很明显：每新增一种动物，都要改 makeAnimalSpeak，加一个 else if。整个系统对“新增”这件事是敏感的，维护成本会越来越高。代码一旦庞大，这种 if-else 链根本撑不住。

1.2 继承和重写让扩展这件事变得自然

正确的思路是把所有动物抽象成一个 Animal 基类，每种具体的动物去重写基类里“发声”这个行为。这样，新增动物时只需要写一个继承 Animal 的新类，完全不用去动已有的老代码。

cpp复制class Animal {
public:
    virtual void speak() { cout << "..." << endl; }
};

class Dog : public Animal {
public:
    void speak() override { cout << "Woof" << endl; }
};

class Cat : public Animal {
public:
    void speak() override { cout << "Meow" << endl; }
};

void makeAnimalSpeak(Animal& animal) {
    animal.speak();
}

这里核心的变化是：maintainer 不再关心对象的具体类型，只要它是 Animal，就可以丢进 makeAnimalSpeak，程序会在运行期根据实际对象的类型找到该调用的函数。这就是函数重写带来的核心价值——面向接口编程、对扩展开放、对修改关闭。

所以别把函数重写当成一个语法点去背，它背后是“接口与实现分离”的工程思想。理解了这一点，你再看 C++ 里各种设计模式的实现，会发现无非是重写在不同场景下换了个姿势。

2. 函数重写的语法与规则核心

2.1 虚函数：打开重写大门的钥匙

在 C++ 里，函数重写不是简单的“在派生类里写一个同名函数”就完事了。关键在于基类的那个函数必须被声明为虚函数，用的是 virtual 关键字。

cpp复制class Animal {
public:
    virtual void speak() const;  // 只有声明为 virtual 的函数才能被派生类重写
};

为什么必须加 virtual？因为 C++ 默认是静态绑定。如果一个函数不是虚函数，那么在编译期看到你调用 animal.speak() 时，编译器只会根据 animal 的静态类型去确定调用哪个函数。只有虚函数才会触发动态绑定，编译器会为这种情况生成查找虚函数表的代码，等运行期拿到对象的真实类型后再决定调用目标。

2.2 重写的四个硬性条件

写对重写，必须同时满足下面四个条件，否则就是“你以为重写了，其实没有”。这几个条件几乎对应着 C++ 面试的高频八股，值得记牢。

• 基类的函数必须是 virtual；
• 派生类的函数签名必须和基类完全一致，参数列表、const 限定符都不能差；
• 返回值类型必须一致，或者满足协变返回类型规则；
• 派生类的函数在继承体系中可见，并且不能是 static 函数。

签名不一致的情况很典型。比如基类是 virtual void speak() const;，结果派生类里写了 void speak();，少了 const。这其实不会编译报错，而是形成隐藏。基类指针调用时，永远走的是基类版本，原因就是签名对不上，编译器压根不觉得这是个重写。

还有一些细节值得注意：访问修饰符不影响重写条件。基类的虚函数是 public，派生类里可以写成 private，依然构成重写。规则是：访问权限影响“能不能被外部调用”，不影响“是不是一个重写”。

2.3 派生类不写 virtual，也可能在重写

有经验的开发者在读别人代码时会看到这样一种写法：基类有个 virtual 函数，派生类重写时前面并没有加 virtual，好像只是在普通成员函数前多了个 override。

cpp复制class Base {
public:
    virtual void f();
};

class Derived : public Base {
public:
    void f() override;  // 没写 virtual，但它依然是虚函数
};

这里要说清楚一个 C++ 规则：一旦基类某个函数被声明为 virtual，它在整个继承层次里都会保持虚属性。派生类即使不写 virtual，它的重写函数依然是虚函数，依然支持动态绑定。在派生类里再次写 virtual 只是让代码更明确而已。

而 override 是在 C++11 加入的，它本身不是语法必需，作用是让编译器帮你检查签名是否真的满足重写条件。用错的时候编译器直接报错，这比运行期发现行为诡异友好得多。

3. 重写、重载、隐藏：千万别再搞混了

3.1 一图看明白三个概念的区别

我自己教过不少初级开发者，几乎每个人都会在这里卡一阵。所以先用一张表把重载、重写、隐藏三个概念放一起对比。

重载讲的是“同一个类里提供多个同名但参数不同的函数”，是为了让一个行为能接收不同类型或数量的参数；重写讲的是“子类对父类虚函数进行替换”，是为了让同一个接口在不同对象上呈现不同行为；隐藏最坑，只要派生类里定义了同名函数，基类的同名函数在派生类作用域里就看不见了。

3.2 隐藏的一个典型翻车现场

隐藏是非常容易出问题的地方，特别是你写的派生类函数和基类虚函数签名不一致时，编译器不警告，代码也能跑，但行为就不对了。

cpp复制class Base {
public:
    virtual void draw(int radius) const {
        cout << "Base draw int" << endl;
    }
};

class Derived : public Base {
public:
    void draw(double radius) const {   // 参数类型不同，不是重写，是隐藏
        cout << "Derived draw double" << endl;
    }
};

Base* p = new Derived();
p->draw(5);    // 输出 Base draw int，并没有多态

问题根源就在 p 的类型是 Base*，编译期看到 draw(int)，而 Derived 里的 draw(double) 签名不同，编译器不认为它是重写，所以调用依旧走静态绑定到 Base 的版本。更麻烦的是，如果你把代码写成 Derived d; d.draw(5)，编译器反而会去找 Derived::draw(double)，把 5 隐式转换成 double 调用，而不会去调用 Base::draw(int)。因为隐藏让 Base::draw(int) 在派生类作用域内被遮盖了。

3.3 重载在派生类里也会被隐藏

隐藏不一定发生在“虚函数和非虚函数”之间。哪怕基类的同名函数有多个重载版本，只要派生类定义了其中一个，其他重载版全部会被隐藏。这时候用 using 声明把基类函数拉回来是个常用解法。

cpp复制class Base {
public:
    void foo(int x) {}
    void foo(double x) {}
};

class Derived : public Base {
public:
    using Base::foo;   // 把基类的所有 foo 拉进派生类作用域
    void foo(int x) {} // 新增派生类自己的版本
};

不加 using 的话，Derived d; d.foo(3.14) 会编译失败，因为编译器在派生类找到了成员函数 foo 后就不会再去基类里翻找，重载集合并没有被自动继承。这个细节在代码审查里特别容易被忽略，但出现频率其实不低。

4. 重写的底层推进器：虚函数表与动态绑定

4.1 虚函数表到底是什么

理解了上面语法层面的东西，接下来该看看重写底层到底是怎么实现的。很多人觉得虚表很神秘，其实用大白话讲，虚表就是一个“类级维护的函数地址表”。

编译器会给每个包含虚函数的类生成一张虚函数表，简称 vtable。这张表本质上是一个数组，按顺序存放该类所有虚函数的入口地址。类的每个实例里面，会存一个隐藏的指针，叫虚指针 vptr，指向自己所属类的那张 vtable。

cpp复制class Base {
public:
    virtual void f1();
    virtual void f2();
    void normalFunc();
};

这里 Base 的 vtable 大致长这样：表里第 0 项是 Base::f1 的地址，第 1 项是 Base::f2 的地址。normalFunc 不是虚函数，它不会进虚表。

如果是 Derived 继承 Base 并且重写了 f1，那么 Derived 的 vtable 第 0 项会指向 Derived::f1，第 1 项仍然指向 Base::f2。这是整个多态机制的核心。

4.2 动态绑定的一次完整旅程

当代码写 Base* p = new Derived(); p->f1(); 时，编译器并不知道 p 到底指向什么对象。它只能生成这样的逻辑：

1. 从 p 指向的对象内存中取出 vptr；
2. 根据 vptr 找到所属类的 vtable；
3. 从 vtable 里取出第 0 个函数地址；
4. 跳转到这个地址执行。

所以运行期走的是 Derived 的 vtable，拿到的是 Derived::f1，调用就自然变成了派生类版本。这个“程序运行后再决定调用谁”的过程，就是动态绑定。

理解了这个机制，很多现象就有了解释。比如为什么虚函数调用比起非虚函数调用多一次间接跳转？因为要先查表。为什么内联那么难触发？因为编译器在不知道对象实际类型的时候做不了内联。为什么带虚函数的类体积会变大一点？因为多了一个 vptr 成员。这些问题在面试里被翻来覆去地问，本质上考的就是你懂不懂这张表。

还有一点很多人没意识到：如果对象是被切片而不是通过指针或引用访问，就不会有动态绑定。比如下面这段直接对象赋值的写法，行为完全不是多态。

cpp复制Derived d;
Base b = d;   // 对象切片，只拷走了 Base 部分
b.f1();       // 仍然是 Base::f1

因为 b 这个对象本身就是 Base 类型，它的 vptr 指向的是 Base 的虚表，赋值动作并不会把派生类的虚表指针拷过来。想用多态，老老实实用指针或引用。

5. 现代 C++ 下的重写控制与常见坑位

5.1 override 和 final：编译器是你的第一道防线

在 C++11 之前，重写完全靠自觉。你写错了签名编译器也不会理你，只会默默变成隐藏。C++11 引入的 override 关键字改变了这种事，它明确告诉编译器“我就是要重写基类的函数”，如果签名对不上，编译器会立刻报错。

我强烈建议团队规范里强制写入：所有重写函数都要加 override。原因很简单，这个关键字让代码意图变得非常明确，而且未来基类如果改了签名，会导致所有重写处编译失败，而不是静默产生错误行为。

final 则是相反的约束：它告诉编译器“这个虚函数到此为止，后面的派生类不许再重写”。

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

class Circle final : public Shape {
public:
    void draw() const override;  // 正确
};

// 下面这样写会直接编译失败
// class SmallCircle : public Circle { ... };

final 可以修饰类，也可以单独修饰函数。如果你写的是一个不应继续被继承的工具类，加上 final 会让设计意图更清晰，同时也给编译器更多优化空间，因为编译器知道这个类没有子类，某些虚函数调用甚至可以做去虚拟化。

5.2 构造函数和析构函数里为什么别调用虚函数

这是个经典面试题，实际工程里也经常有人踩。先给结论：在构造函数或析构函数里调用虚函数，不会触发多态，只会调用当前正在构造或析构的这个类本身定义的版本。

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

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

Derived d;
// 输出是：
// Base
// Derived

创建 Derived 对象时，会先构造 Base 部分，再构造 Derived 自己的部分。在 Base 构造期间，Derived 的成员还没有初始化，编译器要避免你去调用一个依赖未初始化成员的函数，所以它会强制让虚函数解析停留在 Base 层次。换句话说，对象还不是 Derived，vptr 指向的是 Base 的虚表。

析构函数的道理一模一样。析构是先析构派生类部分，再析构基类部分。基类析构执行时，派生类部分已经销毁，虚调用回到基类版本是 C++ 保护你的设计。

5.3 基类析构函数必须写成虚函数吗

这个问题不能一概而论。如果这个类本身设计成基类，或者你打算用基类指针 delete 派生类对象，那么基类析构函数必须加 virtual。

假设基类析构不是虚函数：

cpp复制class Base {
public:
    ~Base();
};

class Derived : public Base {
    std::vector<int> data;   // 管理一些资源
};

Base* p = new Derived();
delete p;

此时 delete p 只会调用 Base 的析构函数，Derived 的析构函数压根不会执行，data 成员不会被释放，内置类型还好，vector 这种会直接内存泄漏甚至崩溃。但基类析构一旦声明为 virtual，delete p 就会走动态绑定，先触发 Derived 的析构，再自动调用 Base 的析构。所以设计继承体系的准则应包含一条：如果类里有 virtual 函数，或者设计上就是让别人继承的，必须把析构函数写成 virtual。

虚析构还有一点容易被忽略：哪怕基类里没有任何函数需要重写，只要确实要作为多态基类，虚析构本来就是 virtual function 的一部分。所以衍生规则是“凡是有虚函数的类，析构函数都要 virtual”，而不是“凡是父类都要 virtual”。

5.4 虚函数和默认参数混用的陷阱

另一个我帮同事排查过的隐蔽问题：重写一个带默认参数的虚函数时，子类给默认参数换了值，预期里根本对不上。

cpp复制class Base {
public:
    virtual void draw(int thickness = 1) const;
};

class Derived : public Base {
public:
    void draw(int thickness = 8) const override;
};

Base* p = new Derived;
Derived* d = new Derived;
p->draw();  // 走的是 Derived::draw 的实现，但 thickness = 1
d->draw();  // thickness = 8

同一个 Derived 对象的同一个函数，通过不同静态类型调用时默认参数居然不一样。原因在于默认参数的取值是编译期静态绑定，C++ 并不会根据运行期的对象类型去决定默认参数。编译器在编译 p->draw() 时，只能看到 Base 的 draw 声明，所以默认参数取 1；真正动态绑定的只有函数本体。解决办法很简单：不要在虚函数上写默认参数，或者设计成公共非虚函数负责默认参数、内部再去调用虚函数。

5.5 协变返回类型和纯虚函数的小细节

关于返回值，常规要求是“必须保持一致”，但有一个例外叫协变返回类型：当基类虚函数返回 Base*（或 Base&）时，派生类可以返回 Derived*（或 Derived&）。

cpp复制class Base {
public:
    virtual Base* clone() const;
};

class Derived : public Base {
public:
    Derived* clone() const override;   // 协变，合法
};

注意这里有个限制：智能指针如 unique_ptr 并不满足协变规则，因为那是 class 层面的模板类型，不是裸指针或引用，编译器不会认为返回 unique_ptr 是对 unique_ptr 的合法协变。很多新手在做 clone 接口时想用可变返回的智能指针，结果编译不过。

纯虚函数还有一个不太为人知的点：它可以有函数体。你看 virtual void f() = 0; 总觉得后面无法实现，其实你完全可以在类外给它写实现，派生类需要通过完整限定符显式调用基类版本的纯虚函数。这在某些需要保留公共逻辑、又强制子类必须重写的场景里非常有用。

cpp复制class Task {
public:
    virtual void execute() = 0;
};

void Task::execute() {
    // 写统一的初始化和收尾逻辑
    cout << "Execute base steps" << endl;
}

class BuildTask : public Task {
public:
    void execute() override {
        Task::execute();   // 显式调用基类纯虚实现
        // build specific
    }
};

6. 代码设计中的重写：用抽象稳住变化

6.1 模板方法模式：把频繁变化的部分留给重写

函数重写真正发挥威力是在设计层面。一个值得反复应用的场景是模板方法模式：基类把算法骨架固定好，把其中一些步骤定义成虚函数，由子类重写细节。

举一个文件导出的例子。假设要做导出 PDF、导出 CSV、导出 Excel 三个类，它们的共同流程都类似“写文件头、写内容、写文件尾”，只是具体内容不同。

cpp复制class FileExporter {
public:
    void exportToFile(const std::string& path) {
        std::ofstream out(path);
        out << buildHeader() << "\n";
        out << buildBody() << "\n";
        out << buildFooter() << "\n";
    }
protected:
    virtual std::string buildHeader() const { return ""; }
    virtual std::string buildBody() const = 0;
    virtual std::string buildFooter() const { return ""; }
};

class CsvExporter : public FileExporter {
protected:
    std::string buildBody() const override {
        return "name,age,city\nAlice,30,Beijing";
    }
};

这个设计把“变化的细节”和“稳定的流程”彻底分开了。客户端的调用永远是 exportToFile，完全不会因导出文件格式不同而修改调用代码。如果后面要支持 JSON 导出，只需要再写一个 JsonExporter 重写 buildBody 就结束。因为重写机制在工作，扩展一个类型等同于增加一个文件，而不是动老代码。

6.2 抽象基类里定义接口契约

如果设计一个接口，希望所有实现者都遵循同一套行为，例如一个支付回调、一个数据库驱动，就应该用纯虚函数把这些方法定义成“纯接口”。

cpp复制class PaymentGateway {
public:
    virtual ~PaymentGateway() = default;
    virtual bool pay(double amount) = 0;
    virtual bool refund(const std::string& orderId) = 0;
};

class AlipayGateway : public PaymentGateway {
public:
    bool pay(double amount) override { /* ... */ }
    bool refund(const std::string& orderId) override { /* ... */ }
};

这背后实际上是在强制各派生类必须提供核心行为。任何一个实现 PaymentGateway 的新类，如果忘了重写 pay 或 refund，编译器就会拒绝实例化，因为纯虚函数没被实现时这个类还是抽象类。这种约定比写文档、开会吼都可靠得多。

6.3 非虚接口 NVI：控制重写的边界

光有接口还不够，生产级代码里经常需要对“重写点”做更精细的管理。这里说一个我很推崇的写法：非虚接口模式，也就是让 public 接口保持非虚，虚函数放进 protected 或 private 区域。

cpp复制class Service {
public:
    void start() {
        // 做一些公共的资源准备、状态管理
        doStart();
        // 做一些校验和日志收尾
    }
private:
    virtual void doStart() = 0;
};

这样设计的好处是：外部调用者只能看到 start 这个非虚的公共接口，没有办法直接调用派生类的 doStart；而派生类只需要关心“启动时要做什么”这一件事。公共逻辑的扩展权完全掌握在基类手中，重写被约束在一个明确的位置，不容易被滥用，也方便基类在虚函数前后追加横切逻辑，比如埋点、加锁、权限校验。

6.4 别让重写破坏基类语义

使用重写时有一个经常被忽略的工程问题：如果派生类重写后做的事情跟基类原本的约定完全不一致，很可能打破调用方的预期。最典型的就是里氏替换原则的违背。

比如基类是一个 Bird，定义了一个 virtual void fly()，企鹅继承之后重写 fly() 直接抛异常，这虽然语法上完全合法，但是所有依赖 Bird 都能飞的对象都会在运行期突然崩溃。设计继承体系时要想清楚：这个虚函数代表的是所有派生类都必须满足的能力，还是只是一部分类可选的扩展？

实际工程里我更倾向于用“能力接口”来隔离这种差异，也就是把“能飞”抽象成另一个接口，让会飞的鸟去实现，而不是把不飞的动物强行塞进一个通用基类再重写掉。重写不是用来否定基类职责的，它应该是为了“在同样职责的前提下，替换实现细节”。

7. 高频面试题与日常避坑速查

结合这些年面试别人和自己被面试的经验，函数重写的考点基本集中在以下几个问题上。整理成一张速查表，方便复习时快速扫一遍。

下面这条清单则是我在实际代码评审和开发中反复提醒自己盯住的高危信号。

• 基类里的某个非虚函数在派生类里被重新定义了，仔细检查这是不是意外隐藏；
• 重写虚函数时漏了 const，导致该重写的函数变成隐藏，代码还不报错；
• 用基类指针保存派生类对象时没注意析构函数是否为 virtual；
• 含有虚函数的类按值传递或按值返回，对象被切片导致多态失效；
• 在构造函数或析构函数里调用虚函数，却指望触发派生类的实现。

这些点看起来都很基础，但真正让项目出问题的恰恰是这类朴素错误。因为编译器通常不会给出明确警告，行为异常往往要到集成测试阶段才会暴露，排查成本一下就上去了。

最后再说一个平时容易被轻视的小经验：写完一个类的重写函数后，刻意用基类指针调一次并观察结果，只用十秒钟，就能把一个隐藏错误提前暴露出来。如果能正常触发派生类版本，再顺手把对象按值切一次验证下切片现象，你在理解多态上会直接上一个台阶。函数重写的语法不难，难的是把背后的绑定机制和设计边界都想清楚，希望你读完这篇文章后能少踩几个坑。