在析构函数中调用虚函数，执行的是当前正在析构的类的版本；因vptr随析构逐层回退，虚调用被静态绑定到当前类实现，派生类重写版本不会被调用，否则可能访问已销毁成员，导致未定义行为。
析构函数里调用虚函数，执行的是当前正在析构的类的版本
结论很直接：在析构函数中调用虚函数，不会触发派生类的重写版本，而是调用「该析构函数所属类」定义的实现。哪怕你通过Derived*指针删除对象，一旦进入Derived::~Derived()，它内部调用的虚函数就只认Derived这一层的虚表；等跳进Base::~Base()时，虚表指针早已被“降级”为Base的虚表——此时连Derived的成员都可能已析构完毕，再调虚函数就是未定义行为。
根本原因在于：析构是逆构造顺序执行的，而vptr会随着每层析构完成而被悄悄重置。编译器在生成析构代码时，会把每层析构函数里的虚调用静态绑定到当前类的虚函数上，不查最终虚表。
- 构造期间：
vptr从Base→Derived逐步更新 - 析构期间：
vptr从Derived→Base逐步回退，且每层析构体内的虚调用都只看到“当前类”的虚表 - 所以
Base::~Base()里调virtual void cleanup()，永远调的是Base::cleanup()，哪怕Derived重写了它
为什么编译器不让你“真正虚起来”
不是编译器不想，而是不能。对象的内存布局在析构过程中是逐步瓦解的：
-
Derived的成员变量（包括Derived独有的数据、子对象）在Derived::~Derived()末尾就被销毁 - 进入
Base::~Base()时，Derived部分的内存已不可靠，若此时还去调Derived::cleanup()，它很可能访问已被析构的成员，引发崩溃或静默错误 - 标准明确将这种情况列为未定义行为（UB），编译器有权不保证任何结果——连警告都不必给
换句话说，C++宁可“保守地不虚”，也不愿“冒险地虚”。这和构造期禁用虚调用是同一套逻辑：类型完整性一旦被破坏，多态就失去意义。
常见踩坑场景与替代方案
最容易出事的地方，是想在析构时统一上报状态、释放资源、注销回调——比如：
- 基类
ResourceHolder析构时调virtual void onReleased()，指望各派生类做定制清理 - 网络模块基类
Connection析构时调virtual void sendClosePacket()，但实际发不出包，因为socket句柄已在派生类析构中关闭
可行的绕过方式只有两种：
- 把需要多态行为的逻辑提前到析构前显式调用，比如加一个
shutdown()或teardown()非虚接口，由用户手动触发 - 用组合代替继承：把可变行为封装成独立对象（如
std::unique_ptr<releasepolicy></releasepolicy>），它的生命周期可控，析构时机明确，不依赖父类虚表状态
最危险的是你以为“反正我只在Derived析构里调虚函数，应该没问题”，但只要这个虚函数被Base的析构函数间接调用（比如通过模板函数、工具类、日志宏），链路一长，你就再也看不到真实调用栈了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
