一、先说结论

在 C++ 中，在析构函数里调用虚函数不会触发你期望的多态行为。此时虚函数调用会被解析为当前正在执行析构的那个类的版本，而不是派生类重写后的版本。如果该虚函数在当前类中是纯虚函数，则属于未定义行为（UB），通常表现为链接错误或运行时崩溃。

换句话说：析构函数里的虚函数调用，永远“只看得到自己这一层”，看不到更派生的子类。

二、为什么会出现这种现象

要理解这个行为，需要先回顾对象的构造与析构顺序，以及虚函数表（vtable）在对象生命周期中的变化。

2.1 构造与析构的顺序

对于一个继承链 Base -> Derived，对象的生命周期是这样的：

1. 构造时：先构造 Base 子对象，再构造 Derived 子对象。
2. 析构时：先析构 Derived 子对象，再析构 Base 子对象。

也就是说，析构顺序与构造顺序完全相反。

2.2 vptr 在析构过程中的切换

含有虚函数的对象通常有一个隐藏的虚表指针 vptr，指向当前“有效”的虚函数表。编译器会在构造和析构过程中不断调整这个指针：

• 进入 Base 构造函数时，vptr 指向 Base 的虚表；
• 进入 Derived 构造函数时，vptr 被改为指向 Derived 的虚表；
• 进入 Derived 析构函数时，vptr 仍指向 Derived 的虚表；
• 进入 Base 析构函数时，vptr 被改回指向 Base 的虚表。

因此，当 Base::~Base() 执行时，Derived 子对象已经被销毁，vptr 也已经回退到 Base。此时任何虚函数调用都只能分派到 Base 的版本。

三、代码示例

下面用一个最小示例直观展示这一行为：

#include <iostream>

class Base {
public:
    virtual ~Base() {
        std::cout << "Base::~Base()\n";
        foo();  // 这里调用虚函数
    }

    virtual void foo() const {
        std::cout << "Base::foo()\n";
    }
};

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

    void foo() const override {
        std::cout << "Derived::foo()\n";
    }
};

int main() {
    Base* p = new Derived();
    delete p;
    return 0;
}

输出结果为：

Derived::~Derived()
Base::~Base()
Base::foo()

可以看到，尽管实际对象是 Derived，Base::~Base() 中调用的 foo() 仍然是 Base::foo()，而不是 Derived::foo()。

四、可能产生的后果

4.1 多态失效，逻辑与预期不符

最常见的后果是行为不符合预期。开发者往往以为析构函数里的虚函数调用会走派生类实现，从而在基类析构中完成“统一清理”，结果实际执行的是基类版本，导致资源没有被正确释放或状态没有被正确更新。

4.2 访问已销毁的派生类成员

即使编译器允许你调用到派生类版本（例如通过某些非标准手段），此时派生类子对象也已经被销毁，访问其成员属于未定义行为。这也是标准禁止这种分派的原因之一。

4.3 纯虚函数导致未定义行为

如果基类析构函数中调用的是纯虚函数，情况更糟：

class Base {
public:
    virtual ~Base() { foo(); }   // 危险！
    virtual void foo() = 0;
};

由于 Base 中 foo 没有实现，析构时调用它属于未定义行为。常见表现是链接期报 undefined reference to Base::foo()，或者运行时直接崩溃（pure virtual method called）。

4.4 难以排查的隐蔽 Bug

这类问题往往在单元测试中不易暴露，只在特定继承层次或特定销毁路径下才出现，排查成本较高。

五、正确做法与替代方案

5.1 不要在析构函数中调用虚函数

最直接的建议就是：避免在构造函数和析构函数中调用虚函数。如果确实需要“销毁前的清理逻辑”，应显式设计一个独立的清理接口。

5.2 使用显式的 cleanup 接口

class Base {
public:
    virtual ~Base() = default;

    // 由使用者显式调用，保证多态生效
    virtual void cleanup() {
        std::cout << "Base::cleanup()\n";
    }
};

class Derived : public Base {
public:
    void cleanup() override {
        std::cout << "Derived::cleanup()\n";
        Base::cleanup();
    }
};

int main() {
    std::unique_ptr<Base> p = std::make_unique<Derived>();
    p->cleanup();   // 多态生效
    return 0;
}

这样清理逻辑在对象仍然完整时执行，多态分派正常，也不会访问已销毁的子对象。

5.3 使用 RAII 管理资源

更推荐的做法是把资源释放交给 RAII 类型（如 std::unique_ptr、std::shared_ptr、std::vector 等），让析构函数只负责成员的自然销毁，从根本上避免在析构中写复杂逻辑。

5.4 需要多态清理时使用模板方法模式

如果确实需要在基类中统一驱动清理流程，可以把“固定流程”放在非虚函数中，把“可变部分”放在虚函数中，但调用点必须在对象完整时：

class Base {
public:
    virtual ~Base() = default;

    void destroy() {
        doDestroy();   // 此时对象完整，多态正常
    }

protected:
    virtual void doDestroy() = 0;
};

六、小结

场景	行为	建议
析构函数中调用普通虚函数	分派到当前类版本，多态失效	避免这样写
析构函数中调用纯虚函数	未定义行为，可能崩溃	严格禁止
构造函数中调用虚函数	同样分派到当前类版本	避免这样写
需要多态清理	显式 cleanup 或模板方法	在对象完整时调用

记住一句话：构造和析构期间，对象处于“半成品”状态，多态机制不可依赖。把清理逻辑显式化、把资源交给 RAII，是更安全、更可维护的 C++ 实践。