删除析构函数变量的存在使得语法

delete ptr;

其中ptr指向多态类型可以工作，即使ptr没有指向最派生的对象。delete ptr;的用户不知道最派生的对象的偏移量或其大小是多少，但为了正确调用operator delete，它需要知道这一点。因此，需要对一个知道的函数进行间接/虚拟调用，即删除析构函数。
不幸的是，编译器必须从这样的virtual析构函数中生成删除析构函数，至少对于所有用作最派生对象的类，因为在另一个翻译单元中可能存在这种类型的delete表达式，它不知道这个最派生析构函数的定义，但它必须（间接）调用。
我不认为你可以将虚拟析构函数的delete行为与执行显式虚拟析构函数调用的能力分开，我也没有看到任何GCC开关来禁用作为非标准/ABI兼容选项的删除析构函数的生成。
所以我想你必须避免使用虚拟析构函数。你可以通过从virtual函数转发来获得虚拟销毁行为：

struct Base {
    virtual destroy() noexcept { this->~Base(); }
    // destructor not virtual
};

struct Derived {
    virtual destroy() noexcept override { this->~Derived(); }
};

然后可以使用ptr->destroy()来代替ptr->~Base();/std::destroy_at(ptr)。
然而，这有一个问题，你需要确保destruct在每个派生类中都被正确地重写，以避免未定义的行为。CRTP或C++23显式对象参数（显式this）可能会有所帮助。
还有一个问题是，有人可能意外地直接调用析构函数，再次导致未定义的行为。创建析构函数private通常也不是一个解决方案，因为析构函数在许多情况下都可能被调用，例如。在一个类的构造函数中，该构造函数包含有问题的类作为非静态成员。
我最初在这里建议将operator delete实现为空，并在每个转换单元中实现inline以帮助删除调用，但我没有意识到将可替换的释放函数标记为inline会使程序IFNDR无效。（参见[替换功能]/3。）
你不能删除operator delete，因为它将被odr使用，因为我上面提到的原因，因此必须可行。
LTO可能会进一步帮助在链接过程中摆脱未使用的删除析构函数，至少通过去虚拟化。但我还没测试过。