像开飞船一样理解C++多态：虚函数与动态绑定全解析

1. 为什么把多态比作飞船的驾驶舱

前几天有个刚学C++的朋友问我一个问题：“多态到底有什么用？我不用虚函数，写一堆if (type == 1)不也一样能干活吗？”

我当时没有立刻回答，而是反问他：如果你写的不是一个魔法值只有两三种的小程序，而是一艘飞船的控制系统——飞船上同时搭载了战斗机、货船、侦察艇三种船型，每种船型的加速方式、武器系统、能源调配逻辑完全不同。你会用switch (shipType)把逻辑全部塞进一个主循环里吗？

他沉默了一会儿说：“那代码会爆炸。”

对，这就是多态存在的意义。多态本质上就是给“不同形态的同类对象”提供一个统一的操作接口，让调用方不需要关心对象的具体类型，只需要对着基类的接口喊话，对象自己就知道该怎么响应。这和飞船驾驶员面对不同的驾驶舱——虽然仪表布局不一样，但你只需要知道油门、摇杆、主屏幕在哪，推进器和武器系统自己会用对应的方式工作——是同一个道理。

很多初学者觉得多态是一堆绕口的术语：虚函数、虚函数表、动态绑定、覆盖。今天我就用“开飞船”这个场景，把C++多态从概念到原理到实战拆个底朝天，顺带把那些面试里常考的“坑”一起翻出来。

这篇文我默认读者是有C++基础的，起码知道class、继承、指针是什么。如果你还在打基础阶段，最好先把类和对象那部分吃透再来看多态，不然容易消化不良。

2. 从函数重载到虚函数：多态的两个层级

2.1 用一个燃尽的引擎问题引出“静态多态”

在聊多态之前，先理清一个概念：多态分两种，静态多态（编译期多态）和动态多态（运行时多态）。

静态多态最典型的就是函数重载（overload）和模板（template）。函数重载的意思是，同一个函数名，参数列表不同，编译器在编译阶段就根据实参类型帮你选好调哪个版本：

cpp复制void boost(Ship& s, int power);       // 普通推进
void boost(FighterShip& s, int power); // 战斗机专属推进

这里调用boost(ship, 10)时，编译器在编译期就确定了到底调哪个函数，所以叫“编译期多态”。它的特点是快，没有任何运行时开销，缺点是不灵活——如果你在运行时才得知对象的具体类型，或者你希望用一个“父类指针”去操作子类对象，静态多态就帮不上忙了。

再说个场景你就有感觉了：你写了一个fly(Ship& s)函数，参数是Ship的引用，但实际传入的是FighterShip对象。如果boost只有Ship版本，那不管传入什么都只会走进Ship的逻辑。假想一下，你用一艘货船的驾驶习惯去推战斗机的加力燃烧室，引擎不烧掉才怪。这就是“编译期就定死协议”的局限。

2.2 虚函数是飞船的自动驾驶切换装置

动态多态的核心就是**虚函数（virtual function）**机制。它的关键在于：调用哪个函数，不在编译期决定，而在运行期根据对象的实际类型决定。用C++行话讲，这叫“动态绑定（dynamic binding）”或“迟绑定（late binding）”。

看个最简例子：

cpp复制#include <iostream>

class Ship {
public:
    virtual void launch() {
        std::cout << "Ship launches with standard thrusters." << std::endl;
    }
    virtual ~Ship() = default;
};

class FighterShip : public Ship {
public:
    void launch() override {
        std::cout << "FighterShip launches with afterburner." << std::endl;
    }
};

void launchAll(Ship* ship) {
    ship->launch();  // 这里的调用会走虚函数机制
}

int main() {
    Ship ship;
    FighterShip fighter;
    launchAll(&ship);
    launchAll(&fighter);  // 输出的不是 Ship 的版本，而是 FighterShip 的版本
    return 0;
}

这个例子虽然短，但信息密度很高。launchAll函数接收的是Ship*类型的指针，却能在运行时识别出实际指向的是FighterShip，并调用FighterShip::launch()。这种“同一个接口，不同实现”的能力，就是面向对象编程里最核心的多态。

注意，我们说的是“基类指针”和“子类实现”之间建立关系。如果是基类指针指向基类对象，那调用的就是基类版本；基类指针指向派生类对象，调用的是派生类版本。这个“运行时”特性，带来的直接好处就是：你可以写一段通用代码，接收任意类型的派生类对象，而代码本身不需要跟着对象类型变化而修改。

3. 内存里到底发生了什么：虚函数表（vtable）拆解

3.1 虚函数表是个“驾驶操作手册”

很多人背下了“虚函数通过虚函数表实现”这句话，但根本不知道虚函数表长什么样。我个人经验是：不理解内存布局，多态就永远是背概念。这里我们用“驾驶操作手册”来类比。

每艘飞船在出厂时（对象构造时），都会在它内部某个位置塞一个隐藏指针——vptr（虚函数表指针），指向一张“驾驶操作手册”——虚函数表（vtable）。这张表里记录下来的是：这个对象实际的每个虚函数地址是多少。

• 基类对象Ship的vptr指向Ship的vtable，表里记录Ship::launch的地址。
• 派生类对象FighterShip的vptr指向FighterShip的vtable，表里记录FighterShip::launch的地址。

当调用ship->launch()时，实际执行的是：通过ship的vptr找到vtable，再从vtable里拿出对应的函数指针，跳转过去执行。这一套流程在运行时完成，与编译时静态绑定不同，因此才有了“动态绑定”的说法。

示意图（这里不用mermaid，直接用ASCII让你有个直观印象）：

code复制FighterShip 对象            FighterShip 的vtable
+--------------+           +-------------------+
|  ...数据成员  |           | type_info 信息     |
| vptr         |----------->| &FighterShip::launch() |
|  ...数据成员  |           | &Ship::~Ship()    |
+--------------+           +-------------------+

3.2 一张表要占多少内存？实测一下

不少人关心性能问题。在绝大多数平台上，一个类的所有虚函数共享一张虚函数表（多继承时一个对象可能有多张表，这个后面讲），表中的每一项是一个函数指针。以64位平台为例，一个函数指针占8字节。如果你有3个虚函数，加上type_info指针等额外信息，一张表通常也就30-50字节，而且这个表是每个类共享一份，不是每个对象一份。

对象本身多出来的开销只有那个vptr——64位平台上是8字节。如果你一个对象只有4字节的int，加虚函数后变成16字节（包含对齐），内存开销并不算小，但对于现代软硬件来说，这个成本绝大多数场景下完全值得。

3.3 对象切片：货船驾驶舱装不下战斗机仪表

有了“飞船”这个比喻，你还能顺便理解一个C++经典大坑——对象切片（object slicing）。

如果你把派生类对象按值赋值给基类对象，比如：

cpp复制FighterShip fighter;
Ship ship = fighter;   // 危险操作

这时会发生切片：派生类对象里基类部分之外的成员被“切掉”，只留下Ship的部分拷给ship。更关键的是，ship内部生成的vptr指向的是基类的虚函数表，而不是 FighterShip的虚函数表。后续ship.launch()调用的必然是Ship::launch。

这就像你硬把战斗机的驾驶舱仪表塞进货船驾驶台里，塞不进去的部分切掉，仪器当然按货船的规程运转。多态必须靠“指针”或“引用”才能成立，按值传递会丢掉类型信息，这是初学者最容易踩的坑，面试也经常拿这个来问。

4. 在代码实践里怎么“开好这艘飞船”

4.1 一个能跑的飞船模拟器

光看理论不够，我们写一个完整的、能编译能运行的小项目，把多态的几种常规操作演示一遍。需求是：

• 有一个抽象基类Ship，定义所有船型的共同接口：launch(加速度)、showStatus()
• 有三条派生类：FighterShip（战斗机）、CargoShip（货船）、ScoutShip（侦察艇）
• 用一个指挥中心CommandCenter统一发射所有飞船

代码示意：

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

class Ship {
public:
    virtual void launch(int power) = 0;
    virtual void showStatus() const = 0;
    virtual ~Ship() = default;
};

class FighterShip : public Ship {
    int afterburnerLevel;
public:
    explicit FighterShip(int level = 0) : afterburnerLevel(level) {}

    void launch(int power) override {
        std::cout << "FighterShip uses afterburner, power level: "
                  << power + afterburnerLevel << std::endl;
    }

    void showStatus() const override {
        std::cout << "FighterShip status: combat-ready." << std::endl;
    }
};

class CargoShip : public Ship {
    double cargoWeight;
public:
    explicit CargoShip(double w = 0.0) : cargoWeight(w) {}

    void launch(int power) override {
        std::cout << "CargoShip lifts off with heavy thrust."
                  << " Cargo weight: " << cargoWeight << " tons." << std::endl;
    }

    void showStatus() const override {
        std::cout << "CargoShip status: hold loaded." << std::endl;
    }
};

class ScoutShip : public Ship {
    int sensorRange;
public:
    explicit ScoutShip(int range = 100) : sensorRange(range) {}

    void launch(int power) override {
        std::cout << "ScoutShip glides out, sensor range: "
                  << sensorRange << " units." << std::endl;
    }

    void showStatus() const override {
        std::cout << "ScoutShip status: scanning." << std::endl;
    }
};

class CommandCenter {
    std::vector<std::unique_ptr<Ship>> fleet;
public:
    void addShip(std::unique_ptr<Ship> ship) {
        fleet.push_back(std::move(ship));
    }

    void launchAll() {
        for (const auto& ship : fleet) {
            ship->launch(10);
            ship->showStatus();
        }
    }
};

int main() {
    CommandCenter center;
    center.addShip(std::make_unique<FighterShip>(5));
    center.addShip(std::make_unique<CargoShip>(120.5));
    center.addShip(std::make_unique<ScoutShip>(300));

    center.launchAll();
    return 0;
}

运行结果大概是这样：

code复制FighterShip uses afterburner, power level: 15
FighterShip status: combat-ready.
CargoShip lifts off with heavy thrust. Cargo weight: 120.5 tons.
CargoShip status: hold loaded.
ScoutShip glides out, sensor range: 300 units.
ScoutShip status: scanning.

注意这时候CommandCenter::launchAll()里根本不需要知道vector里存的是哪一种船。它面对的是Ship，但调用的是各种具体飞船的行为。**你的业务代码因此变得极其干净，加新船型只需要新增一个派生类，而CommandCenter一行都不用改。**这就是多态最值钱的工程意义。

4.2 为什么我推荐用智能指针管理多态对象

上面的代码里我用了std::unique_ptr<Ship>，这是我自己写多态代码时的“默认配置”。

在多态场景里，基类析构函数常被声明为virtual，否则通过基类指针delete派生类对象时，派生类的析构逻辑不会被调用，内存很可能泄漏（后面细讲）。而std::unique_ptr在生命周期结束时，会以正确的类型调用析构——即使基类析构是虚的，它也会完整地走一遍派生类析构再走基类析构。

同时unique_ptr是独占所有权语义，代码意图明确：addShip传进来一份所有权，CommandCenter负责管理这份所有权。如果你需要多个地方共享同一艘飞船，再换std::shared_ptr。这一步选择，靠的是对C++所有权模型的熟悉，而不仅仅是为了“不手动delete”。

4.3 抽象基类：飞船设计图上不存在的船

在上面的代码里，Ship类里launch(int)和showStatus() const都是纯虚函数（pure virtual function），写法是= 0。有纯虚函数的类叫抽象基类（abstract base class）。

抽象基类在工程上相当于“设计图纸”：你不可能直接产出一艘“船”，因为“船”是个抽象概念；你生产的一定是战斗机、货船或侦察艇。这就保证了没有人会写出Ship s;这种没有实际意义的代码——因为编译器连编译都不让你过：

cpp复制Ship ship;  // 编译错误：cannot instantiate abstract class

这个设计对我个人来说，特别适合定义“接口契约”。接口里只规定“我要能launch，我要能showStatus”，至于具体过程，由每个派生类自行实现。只要大家都遵守这个契约，上层调用逻辑就能稳定运行。

5. C++多态和三件法宝：析构函数、override、final

5.1 为什么基类析构函数几乎必须声明为virtual

如果说多态有一个“不遵守就出事”的铁律，那就是：基类析构函数必须声明为虚析构函数。

假设你把Ship的析构函数设成非虚，然后在CommandCenter::launchAll结束后，unique_ptr<Ship>析构时只会调用Ship::~Ship()，而不会调用 FighterShip的析构函数。对于FighterShip里有afterburnerLevel这种内置类型还好，如果它持有一个std::vector<int>、一个std::string或一块new[]出来的动态内存，那析构漏调，轻则资源泄漏，重则程序崩溃。

我见过一个线上Bug，就是某个插件系统在派生类里申请了堆内存，基类析构非虚，卸载插件时内存没有被释放。结果就是进程长时间运行后内存占用一路飙升，最后被系统杀掉。排查起来非常痛苦，因为你从业务逻辑上看不出任何问题。

建议：凡是写了一个有虚函数的类，顺手把析构函数也声明为virtual（或virtual ~Ship() = default;），这是C++社区的通用实践，也能避免后人踩坑。

5.2 override：给你的覆写系上安全带

override是C++11引入的一个修饰符，它不是必须的，但强烈推荐写。如果某个派生类函数声明为override，编译器会强制检查：基类里是否有一个对应的虚函数，且签名完全匹配。

cpp复制class FighterShip : public Ship {
public:
    void launch(int power) override;    // 正确
    // void launch(double power) override; // 编译错误：基类没有这个签名
};

如果你漏了override，然后又写错了签名（比如把launch(int)写成了launch(double)），编译器不会报错，只会静默地认为你在派生类里定义了一个新的隐藏函数，而不是覆写基类的虚函数。这种错误极其隐蔽，往往运行时行为和你预期不符，还不好定位。

也有不少老代码不写override，这没错，但那是过去的风格。现在新代码我一般要求自己“凡覆写必写override”，几毫秒的打字成本换来的是一次编译器级别的保障，非常划算。

5.3 final与默认参数：两个容易踩的小坑

final修饰符的作用是：禁止这个类被继续继承，或者禁止这个虚函数被继续覆写。用在设计上，比如你确定FighterShip已经是最具体形态，不希望有人再派生一个StealthFighter，就可以写：

cpp复制class FighterShip final : public Ship { ... };

final的价值在于明确设计意图，同时也能给编译器更多优化空间。不过我得提醒一句：final很容易被滥用。除非你非常确定这个类不会作为基类，否则别急着堵死后路，很多以后需要的扩展性，都被“提前final”给掐断了。

还有一个高频陷阱是虚函数的默认参数。

cpp复制class Ship {
public:
    virtual void accelerate(int power = 10) {
        std::cout << "Ship accelerate with power: " << power << std::endl;
    }
};

class FighterShip : public Ship {
public:
    void accelerate(int power = 99) override {
        std::cout << "FighterShip accelerate with power: " << power << std::endl;
    }
};

Ship* s = new FighterShip();
s->accelerate();  // 输出什么？

答案是“FighterShip accelerate with power: 10”。虚函数的默认参数是静态绑定的，也就是说编译器在编译s->accelerate()时，根据s的静态类型Ship*，取的是Ship::accelerate的默认参数10。虽然实际调用的是FighterShip的实现，但默认参数却是基类的。这是C++标准明确规定的行为，几乎每个学多态的人都会在这里被坑一次。

经验：虚函数里的默认参数能不用就不用。如果实在需要，保持基类和所有派生类的默认参数一致，否则你永远猜不到调用方会传入什么值。

6. 动态类型识别与安全向下转换（RTTI）

6.1 dynamic_cast的适用场景

多态运行时，有时候你确实需要知道对象的真实类型，从而进行一些只有派生类才有能力执行的操作。比如，侦察艇有scanArea()，货船没有，你要在舰队里找出所有ScoutShip逐一扫描。

这时候可以用**RTTI（Runtime Type Information，运行时类型信息）**机制，配合dynamic_cast进行安全的向下转换：

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

class ScoutShip : public Ship {
public:
    void scanArea() {
        std::cout << "ScoutShip scanning area..." << std::endl;
    }
};

void scanScouts(const std::vector<std::unique_ptr<Ship>>& fleet) {
    for (const auto& ship : fleet) {
        auto* scout = dynamic_cast<ScoutShip*>(ship.get());
        if (scout) {
            scout->scanArea();
        }
    }
}

如果ship确实指向ScoutShip，转换成功，scout指向有效对象；如果指向其他类型，转换结果是nullptr。代码里判断一下scout是否为nullptr，就可以安全地只对侦察艇操作。

6.2 dynamic_cast与虚函数表的关系

dynamic_cast的实现通常依赖于虚函数表里的type_info指针。前面提到过，虚函数表里存的不只是函数指针，还包含类型信息。也就是说：只有具备虚函数的类才能使用dynamic_cast处理（实际上运行时类型识别要求至少有一个虚函数），因为没有虚函数就没有vtable，也就没有类型元数据。

这也解释了为什么纯虚基类的析构函数几乎都要声明为virtual：它不仅保证了析构安全，还让这个类成为一个“多态类型”，从而支持dynamic_cast和typeid操作。

6.3 什么时候不该用dynamic_cast

虽然dynamic_cast很强大，我个人的原则是：能用多态接口解决问题，就不要用dynamic_cast。

如果一个函数需要对不同派生类执行不同的操作，而你又不得不在函数里写一堆if (dynamic_cast<FighterShip*>)，这通常说明你抽象出来的接口粒度不对。正确的做法是把这些“差异操作”提取成虚函数，放进基类，让每个派生类自己实现，上层调用统一接口就好。

dynamic_cast的真正用武之地，是在“对象本身参与了某种跨类型协作”的场景里。比如一个ScoutShip只能与CargoShip对接以补充燃料；而在接口层面，你没法把“对接货船”提炼成一个普适虚函数，那这时候类型识别就说得通。

7. 多继承、菱形继承和虚继承的“飞船编队”

7.1 多继承时的vtable布局

C++支持一个类同时继承多个基类，比如FighterShip既继承Ship又继承WeaponSystem。这时候对象内部会包含多个vptr，每个基类对应一套虚函数表。

code复制FighterShip 对象布局（简化）
+---------------------------+
| Ship基类子对象             |
|   vptr ---> Ship的vtable   |
+---------------------------+
| WeaponSystem基类子对象    |
|   vptr ---> WeaponSystem的vtable |
+---------------------------+
| FighterShip自身新增成员    |
+---------------------------+

当你把FighterShip*转换为Ship*或WeaponSystem*时，编译器会自动调整指针的偏移量，让其指向对应的基类子对象。这一过程是编译期完成的，运行时代价为零。

7.2 菱形继承：飞船变异的幽灵

菱形继承是多继承里最容易出问题的形态：

cpp复制class Vehicle { public: int speed = 0; };
class AirShip : public Vehicle { };
class SeaShip : public Vehicle { };
class AmphibiousShip : public AirShip, public SeaShip { };

这里AmphibiousShip里会有两个Vehicle子对象，分别是AirShip::Vehicle和SeaShip::Vehicle。访问speed会出现二义性，你不得不写成obj.AirShip::speed或obj.SeaShip::speed。更麻烦的是，如果你把一个AmphibiousShip传给某个接收Vehicle&的函数，指针转换路径不唯一，编译器会直接报错。

解决办法是虚继承（virtual inheritance）：

cpp复制class AirShip : virtual public Vehicle { };
class SeaShip : virtual public Vehicle { };

虚继承会让AmphibiousShip里只有一个Vehicle基类子对象。作为代价，对象的布局会更复杂，虚继承的实现也依赖一些隐藏指针，性能上有轻微损失。所以只有在确实需要解决菱形继承二义性时才用虚继承，别为了炫技给所有继承都加上virtual。

7.3 多继承的替代方案

很多现代C++设计里，多继承被用得很克制。更常见的做法是组合 + 接口：用一个主继承链表达“是什么”，用若干个抽象接口表达“能做什么”。

code复制class FighterShip : public Ship, public IFighter {
    // IFighter是只有纯虚函数的接口类
};

这样既保留多态能力，又避免了继承层次过深带来的复杂性。从工程经验来说，优先组合、谨慎多继承，这个原则比C++语法本身的细节更值钱。

8. 多态与设计模式：如何让飞船舰队自己组织起来

8.1 工厂模式：统一生产飞船

多态和设计模式是天生一对。最常见的配合就是工厂模式：你不想让上层业务代码知道具体要创建哪个派生类，而是告诉工厂“我要战斗型”，工厂返回一个Ship*。

cpp复制enum class ShipClass { Fighter, Cargo, Scout };

std::unique_ptr<Ship> makeShip(ShipClass type) {
    switch (type) {
        case ShipClass::Fighter:
            return std::make_unique<FighterShip>(3);
        case ShipClass::Cargo:
            return std::make_unique<CargoShip>(88.8);
        case ShipClass::Scout:
            return std::make_unique<ScoutShip>(200);
    }
    return nullptr;
}

上层这样用：

cpp复制auto ship = makeShip(ShipClass::Scout);
ship->launch(10);  // 具体是哪艘船，上面根本不用管

这就是依赖倒置思想的体现：上层不依赖具体实现，只依赖Ship这个抽象接口。新增船型时，只需要在工厂里加一个分支，上层完全不动。

8.2 策略模式：飞行模式动态切换

多态还可以用来实现策略模式。假设飞船的飞行模式有巡航、突防、隐遁三种，每种模式的物理参数不一样。把每种策略封装成独立类，通过在运行期换用不同策略对象，就能改变船的行为。

cpp复制class FlightStrategy {
public:
    virtual float computeThrust(float input) = 0;
    virtual ~FlightStrategy() = default;
};

class CruiseStrategy : public FlightStrategy {
public:
    float computeThrust(float input) override { return input * 1.2f; }
};

class StealthStrategy : public FlightStrategy {
public:
    float computeThrust(float input) override { return input * 0.4f; }
};

这样就不用把策略的if...else堆在飞船类内部了——每种策略都是独立可测试的类，飞船类里只持有一个FlightStrategy*，想换就换。工程上更容易扩展，也更容易维护。

8.3 多态和回调函数的关系

在C++里，回调函数本身不一定需要多态来完成，std::function和函数指针都能做到。但多态在某些需要“按对象类型绑定回调”的场景下更自然。举个例子，一个事件系统里，每种飞船对接收到“损毁”事件的处理方式不同，你可以让Ship提供virtual void onDamaged(int damage)=0，每种船按自己的规则响应。这就是多态天然适配“事件驱动”的体现。

9. 性能成本与底层优化视角

9.1 虚函数调用的两跳

虚函数调用比普通函数调用多了一层间接性。普通调用在编译期确定地址，直接call；虚函数调用要经历：

1. 通过对象内存中的vptr找到vtable。
2. 从vtable中取出目标函数地址。
3. 跳转到该地址执行。

这两次寻址相对于直接调用确实有微小的额外开销。现代CPU的分支预测和缓存机制能把这个开销压得很低，在一次函数体内做大量工作时，这点损耗几乎可以忽略不计。但对于某些高频调用的短小函数（比如每帧执行上万次、只有几条指令的情况），虚函数调用开销可能就不能忽视了。

9.2 编译器优化：final和devirtualization

现代编译器在开启优化后，会尝试做去虚化（devirtualization）。如果编译器能确定某个虚函数调用实际指向的具体类型，它会直接把虚调用改写为直接调用，消除虚函数表查找的开销。

cpp复制class FighterShip final : public Ship { ... };

void test() {
    FighterShip fs;
    Ship* s = &fs;
    s->launch(10);  // 编译器可能直接内联调用FighterShip::launch，因为fs的实际类型已经明确
}

加上final，等于告诉编译器“你不用担心还有别的子类”，编译器就能更放心地做去虚化。在性能敏感的核心循环里，合理使用final确实能带来可观的优化空间。

9.3 什么时候该放弃虚函数

虚函数不是唯一选择。C++的模板可以做到编译期多态，即所谓静态多态。std::vector、std::sort就是典型例子——它们不依赖虚函数，而是靠模板参数在编译期生成具体代码。这样，所有调用都是静态绑定的，没有虚函数表查找，也没有运行时类型识别，性能极高。

我在写网络协议解析、图像处理这类性能敏感模块时，如果能够在编译期确定所有类型，就会优先选择模板而不是虚函数。但相应地，模板代码的可读性通常比虚函数方案差，编译时间也更长，所以要在灵活性和性能之间做权衡。多态不是银弹，它只是其中一个工具。

10. 走向高级用法：CRTP与编译期多态为什么越来越流行

既然聊到模板，得提一个被誉为“奇异递归模板模式”的——CRTP（Curiously Recurring Template Pattern）。它看起来甚至有点奇怪：派生类把自己作为模板参数传给基类。

cpp复制template <typename Derived>
class ShipBase {
public:
    void launch() {
        static_cast<Derived*>(this)->launchImpl();
    }
};

class FighterShip : public ShipBase<FighterShip> {
public:
    void launchImpl() {
        std::cout << "FighterShip launches with afterburner." << std::endl;
    }
};

调用ship.launch()时，ShipBase<FighterShip>::launch里通过static_cast把this转成Derived*，再调用FighterShip::launchImpl。整个过程在编译期就确定了，没有虚函数表，没有指针间接跳转，宏展开前也是静态类型检查的，所以更快，也更安全。

这一技巧在需要“高性能多态”的场合非常有用。比如某些游戏引擎的实体组件系统、物理引擎的碰撞检测，都大量使用CRTP来获得类似多态的表达能力。但也有代价——CRTP的代码不易读懂，模板错误信息很劝退，容易把项目搞得很难维护。所以在团队项目里用CRTP前，得先考虑团队成员是否具备相应的技术储备。

11. 实战总结：从“看懂代码”到“写出优秀的多态代码”

11.1 一个完整的多态项目检查清单

在你动手写一个多态相关的模块时，我建议按这份清单自查：

• 基类的析构函数是否声明为virtual？
• 派生类覆写虚函数时是否写了override？
• 需要覆盖或禁止继承的地方是否写了final？
• 用基类指针或引用管理派生类对象时，是否避免了按值传递（切片问题）？
• 是否必要地使用了dynamic_cast？能不能通过完善接口来避免？
• 是否在虚函数里写了默认参数？
• 使用std::unique_ptr还是std::shared_ptr来管理对象所有权，选择是明确的吗？
• 如果有多继承，是否真的需要？虚继承是否必要？
• 如果对性能敏感，是否可以考虑用CRTP或模板替代虚函数？

11.2 多态代码的维护经验

从我自己的开发经验来说，多态代码最大的维护难题不在语法，而在设计得是否内聚。一个糟糕的多态设计，会有十几个纯虚函数挤在一个接口里，派生类实现每个函数都苦不堪言，还经常需要空实现。这其实是“接口过于臃肿”的坏味道。

好的接口设计应该是小而专：Ship只关心launch和showStatus；能飞的和能战斗的，各自拆成独立接口IFlyable和IFighter。这样每种船都只实现与自己能力相关的接口，职责清晰，测试起来也容易。

11.3 最后说点心得

在C++多态这条路走了这么多年，我的体会是：多态最大的价值不是帮你少写几个if，而是帮你把“变化”和“稳定”解耦——船舶类型会变，但指挥中心的调度逻辑可以保持不变；传感器算法会变，但主控流程可以保持不变。

真正掌握多态，不是你背出了虚函数表的结构，而是你写代码时自然而然地思考：这一层是稳定的接口，这一层是易变的实现，它们之间靠什么连接？ 多态，就是那个连接点。把飞船开到这一步，才算真正掌握了自己的驾驶舱。