历史： 在 C++98 中，资源管理遵循三法则：如果一个类需要自定义析构函数、复制构造函数或复制赋值运算符，那它很可能需要这三者。随着 C++11 引入移动语义，这变成了五法则，增加了移动构造函数和移动赋值运算符。标准委员会选择了一种保守的方法：声明任何析构函数（甚至是微不足道的）会抑制隐式生成的移动操作，以防止误用资源的浅表移动。
问题： 当你在类定义中写 ~MyClass() = default; 时，你创建了一个 "用户声明的" 析构函数。根据 C++ 标准 ([class.copy.ctor]/3)，这会抑制移动构造函数和移动赋值运算符的隐式声明。因此，编译器将该类视为仅拷贝的，在 std::vector 重新分配或返回值优化期间，默默地回退到开销较大的拷贝语义，即使析构函数根本不执行实际工作。
解决方案： 为了保持隐式移动生成，只在类内声明析构函数，并在外部提供默认定义：
class Optimized { public: ~Optimized(); // 仅在此处声明 std::array<char, 4096> buffer; }; Optimized::~Optimized() = default; // 在外部定义
这使析构函数在编译器决定生成移动的时刻成为"用户提供的"而不是"用户声明的"。另外，可以显式地默认所有五个特殊成员，或者更好地遵循零法则，通过用 std::unique_ptr 或容器替换原始资源。
我们在一个高频交易引擎中遇到了这个问题，该引擎处理 MarketDataPacket 对象。该类为网络数据保留了一个固定的4KB缓冲区：
class MarketDataPacket { public: ~MarketDataPacket() = default; // 为了 "清晰性" 而写在头文件中 char buffer[4096]; };
在迁移到 C++11 后，延迟分析显示40%的CPU周期消耗在 memcpy 上，尽管按值返回数据包。罪魁祸首是类内默认析构函数，它无意中删除了隐式移动，并强制在 std::vector 扩展和函数返回期间进行复制。
解决方案1： 显式声明 noexcept 移动构造函数和赋值运算符。这立即解决了性能问题并启用移动。然而，它在添加成员时需要手动维护这些函数，如果涉及原始指针则存在异常规范不匹配的风险，并增加了违反零法则的样板代码。
解决方案2： 将析构函数定义移动到 .cpp 文件，使用 MarketDataPacket::~MarketDataPacket() = default;。这恢复了编译器生成的移动，同时保持析构函数微不足道。它保持了零开销抽象，并允许编译器进行诸如消除未使用对象的析构函数调用的优化。唯一的缺点是需要一个单独的编译单元，这是可接受的。
解决方案3： 用 std::vector<uint8_t> 或 std::unique_ptrstd::byte[] 替换原始缓冲区。这实现了完美的零法则合规。然而，在对微秒敏感的交易路径中，引入间接或堆分配开销是不可接受的，缓存局部性至关重要。
我们选择了 解决方案2。通过将默认化移到类外，我们恢复了隐式移动，将数据包处理延迟从12μs减少到3μs，并保持了微不足道的可销毁性，以便进行积极的编译器优化。
为什么编译器在类内和类外默认化时会区分，尽管语义相同？
区别在于语法，而非语义。C++ 为类定义采用单次解析模型。当编译器到达类的闭合括号时，必须决定是否生成隐式移动操作。如果它在内部看到 = default，则此时析构函数被视为 "用户声明的"，触发根据 [class.copy]/7 的抑制规则。编译器无法 "向前查看" 外部定义以更改此决策。这是 C++ 的编译模型中一个基本的限制。
标记析构函数为 noexcept 是否能恢复隐式移动？
不可以。隐式移动生成的抑制完全取决于析构函数是否被用户声明，而不是其异常规范。虽然将移动标记为 noexcept 对于在 std::vector 重新分配时被使用至关重要，但仅仅将 noexcept 添加到类中的默认析构函数并不会恢复被删除的移动操作。你必须将定义移到外部或显式默认移动。
用户声明的析构函数如何影响聚合初始化？
任何有用户声明析构函数的类都不再是聚合。这通常比失去移动更具破坏性。这意味着失去指定初始化器 (C++20) 和在没有显式构造函数的情况下使用花括号封闭的初始化列表的能力。许多开发者期望聚合初始化能够工作，当它失败时感到惊讶：
struct Config { ~Config() = default; // 破坏聚合 int value; }; // Config c{42}; // 错误：没有匹配的构造函数
这发生的原因是，用户声明的析构函数的存在强迫类在类型系统中具有非平凡的销毁语义，无论实际复杂性如何，均不符合聚合状态。