1. 静态绑定：编译器只看表达式类型#

先看没有 virtual 的版本：

1
#include <iostream>
2

3
class Task {
4
public:
5
    void run() const {
6
        std::cout << "base task\n";
7
    }
8
};
9

10
class NetworkTask : public Task {
11
public:
12
    void run() const {
13
        std::cout << "network task\n";
14
    }
15
};
16

17
void execute(const Task& task) {
18
    task.run();
19
}
20

21
int main() {
22
    NetworkTask task;
23
    execute(task);
24
}

这段代码输出 base task。NetworkTask::run 只是隐藏了同名函数，不构成运行时覆盖。execute 里的参数类型是 const Task&，编译器在编译期就确定调用 Task::run。

这类调用叫静态绑定。它并不差：普通成员函数、函数重载、模板实例化都依赖编译期确定的调用关系。问题只是，当行为确实要随对象实际类型变化时，静态绑定不够用。

2. 动态绑定需要三个条件#

把基类函数声明为 virtual：

1
#include <iostream>
2

3
class Task {
4
public:
5
    virtual ~Task() = default;
6

7
    virtual void run() const {
8
        std::cout << "base task\n";
9
    }
10
};
11

12
class NetworkTask final : public Task {
13
public:
14
    void run() const override {
15
        std::cout << "network task\n";
16
    }
17
};
18

19
void execute(const Task& task) {
20
    task.run();
21
}

这段代码中，execute(NetworkTask{}) 会调用 NetworkTask::run。动态绑定成立要同时满足三件事：

1. 基类成员函数声明为 virtual
2. 派生类使用相同签名覆盖它，最好写 override
3. 调用通过基类指针或基类引用发生，并且实际对象是派生类对象

如果直接用 NetworkTask 对象调用 run()，当然也会进入派生类实现，但那不是动态绑定。动态绑定的价值在于：调用点只依赖 Task 接口，却仍能处理不同的具体任务。

3. vptr 和 vtable 是常见模型，不是标准承诺#

主流编译器通常会用“对象里保存一个隐藏指针，类型对应一张函数表”的模型实现虚函数。常见术语是 vptr 和 vtable。

一次虚函数调用可以粗略理解为：

1. 通过基类引用或指针拿到实际对象
2. 从对象的隐藏信息找到该实际类型对应的虚函数表
3. 从表中取出 run 对应的函数地址
4. 调用派生类实现

这个模型能解释为什么相同的 Task& 会调用不同派生类行为，也能解释为什么带虚函数的对象常常比没有虚函数的对象多一些实现层面的开销。

但要保持边界：C++ 标准没有规定对象必须有 vptr，也没有规定 vtable 的布局、位置或函数顺序。 它们是常见实现策略，不应该被当成可移植的对象内存布局来依赖。

4. 抽象接口：让调用方依赖行为，不依赖具体类型#

工程里更常见的写法是把基类做成抽象接口：

1
#include <string_view>
2

3
class Task {
4
public:
5
    virtual ~Task() = default;
6

7
    virtual std::string_view name() const = 0;
8
    virtual void run() = 0;
9
};

这段代码里，Task 不能直接构造，因为它有纯虚函数。它只描述任务必须具备的行为：能提供名称，也能执行。

具体任务各自实现接口：

1
#include <iostream>
2

3
class FlushLogTask final : public Task {
4
public:
5
    std::string_view name() const override {
6
        return "flush log";
7
    }
8

9
    void run() override {
10
        std::cout << "flush log buffer\n";
11
    }
12
};
13

14
class ReconnectTask final : public Task {
15
public:
16
    std::string_view name() const override {
17
        return "reconnect";
18
    }
19

20
    void run() override {
21
        std::cout << "reconnect server\n";
22
    }
23
};

这段代码让两种任务的内部细节完全不同，但调用方只需要认识 Task。final 表示这里不准备继续派生；它主要表达设计意图，不是为了追求某个微优化。

5. 异构对象放进容器时，把所有权写清楚#

std::vector<Task> 行不通：抽象类不能按值存储，而且按值存储基类还会带来对象切片。更合适的写法是让容器拥有多态对象：

1
#include <memory>
2
#include <vector>
3

4
class TaskExecutor {
5
public:
6
    void add(std::unique_ptr<Task> task) {
7
        tasks_.push_back(std::move(task));
8
    }
9

10
    void runAll() {
11
        for (const auto& task : tasks_) {
12
            task->run();
13
        }
14
    }
15

16
private:
17
    std::vector<std::unique_ptr<Task>> tasks_;
18
};

这段代码里，TaskExecutor 独占任务对象。unique_ptr 不能拷贝，只能移动，所以 add 明确接收所有权，tasks_ 析构时会自动销毁所有任务。

调用方创建并移交任务：

1
int main() {
2
    TaskExecutor executor;
3

4
    executor.add(std::make_unique<FlushLogTask>());
5
    executor.add(std::make_unique<ReconnectTask>());
6

7
    executor.runAll();
8
}

这段代码没有裸 new，也没有手写 delete。每个对象的生命周期由 unique_ptr 管理，runAll 通过 Task 接口触发动态绑定。

这里的关键不是“必须使用智能指针”，而是对象所有权不能模糊。谁创建任务，谁拥有任务，谁决定销毁任务，都应该能从类型里看出来。

6. override、final 和虚析构函数都是接口约束#

override 应该作为覆盖虚函数时的默认写法：

1
class Task {
2
public:
3
    virtual void run() = 0;
4
};
5

6
class NetworkTask final : public Task {
7
public:
8
    void run() override {}
9
};

这段代码里，override 要求 NetworkTask::run 必须真的覆盖基类虚函数。比如不小心写成 void run() const，编译器会直接报错，而不是悄悄创建另一个同名函数。

只要对象可能通过基类指针被销毁，基类析构函数就必须是虚函数：

1
class Task {
2
public:
3
    virtual ~Task() = default;
4
    virtual void run() = 0;
5
};

这段代码保证 std::unique_ptr<Task> 销毁派生对象时，会先调用派生类析构函数，再调用基类析构函数。没有虚析构函数，通过基类指针删除派生对象会产生未定义行为。

final 可以放在派生类或虚函数上，表达“不允许继续覆盖或派生”。它适合用于设计已经收敛的类型，不应该机械地给所有类都加上。

7. 三个常见风险#

1
#include <iostream>
2

3
class Message {
4
public:
5
    virtual void print() const {
6
        std::cout << "base message\n";
7
    }
8
};
9

10
class TextMessage final : public Message {
11
public:
12
    void print() const override {
13
        std::cout << "text message\n";
14
    }
15
};
16

17
void printMessage(Message message) {
18
    message.print();
19
}

1
class Task {
2
public:
3
    Task() {
4
        configure();
5
    }
6

7
    virtual void configure() {}
8
};
9

10
class NetworkTask final : public Task {
11
public:
12
    void configure() override {
13
        // 此时派生类成员尚未完成构造
14
    }
15
};

8. 运行时多态、模板和组合怎么选#

三种方式解决的问题不同：

TaskExecutor 需要在运行时存储不同任务，因此运行时多态合理。一个只在编译期选择算法的数值计算模块，模板往往更直接。一个任务要附加重试或日志能力，优先考虑组合，而不是再造一层继承。

不要把虚函数当成默认设计。先问一句：调用方是否真的只依赖抽象接口，而且具体实现是否会在运行时变化？答案是肯定的，再引入运行时多态。

9. 面试里可以准确回答什么#

如果被问到“为什么基类指针能调用派生类函数”，可以把回答压缩成几句：

1. 基类函数必须是 virtual
2. 调用要通过基类指针或引用发生
3. 实际对象必须是派生类对象
4. 主流实现通常通过 vptr/vtable 找到覆盖函数，但这不是 C++ 标准规定的内存布局

继续往工程侧补充：基类析构函数要是虚函数；异构对象通常由 std::unique_ptr<Base> 管理；避免对象切片；构造和析构阶段不要依赖派生类虚行为。

10. 小结#

这一篇可以先记住：

1. 静态绑定看表达式类型，动态绑定看对象实际类型
2. virtual、基类指针或引用、派生实际对象共同构成动态绑定条件
3. vptr/vtable 是常见实现模型，不是标准布局承诺
4. 抽象接口描述行为，unique_ptr<Base> 把多态对象所有权写清楚
5. override、final 和虚析构函数让接口约束更明确
6. 对象切片、构造析构期间虚调用、过度继承是最常见的设计风险
7. 运行时多态只在运行时需要抽象替换时使用，其他场景优先考虑模板或组合

虚函数真正解决的不是“怎么把函数调到派生类”，而是让调用方依赖稳定接口，同时把具体实现和对象所有权留在合适的边界里。