历史：在 C++11 之前，std::vector 在重新分配时完全依赖于复制操作，因为移动语义并不存在。C++11 引入移动语义承诺了显著的性能提升，但引入了一个关键的安全难题：如果在重新分配过程中移动构造函数抛出异常，则容器无法轻松回滚，因为源对象可能已经处于被移动状态。
问题：当 std::vector 耗尽其容量并需要增长时，它必须将现有元素转移到新内存中。如果在此过程期间发生异常，强异常安全保证要求容器保持原始状态（全有或全无的语义）。然而，抛出移动构造函数会破坏这一点，因为它们会以破坏性方式修改源对象；如果第 100 次移动抛出异常，那么之前的 99 个元素已经被销毁或失效，导致无法回滚。
解决方案：C++ 标准规定 std::vector 使用 std::move_if_noexcept（或通过 std::is_nothrow_move_constructible 进行等效编译时特征检测）在移动和复制操作之间进行选择。如果元素类型的移动构造函数没有标记为 noexcept，则向量会保守地回退到复制操作。由于复制操作保留源对象的完整性，因此可以捕捉异常，原始缓冲区保持不变，保留强保证。
struct Data { std::vector<int> payload; // 危险：隐式 noexcept(false)，因为 vector 的移动不符合 noexcept Data(Data&& other) noexcept(false) : payload(std::move(other.payload)) {} Data(const Data&) = default; }; std::vector<Data> v; v.reserve(2); v.push_back(Data{}); v.push_back(Data{}); // 在下一个需要增长的 push_back 时： // 如果 Data 的移动不是 noexcept，vector 将复制所有元素
问题描述：在一个高频交易引擎中，我们维护了一个 std::vector 的订单簿快照，代表实时市场深度。在市场开放的峰值期间，向量需要频繁增长。该系统要求超低延迟（微秒敏感性）和绝对的崩溃安全性—在重新分配过程中，任何异常不能破坏订单簿状态或导致内存泄漏。
解决方案 1：提前预留和过度配置 我们考虑提前分配巨大的容量（例如，100 万个元素）以完全避免重新分配。优点：消除了在增长期间发生异常的风险，保证了指针稳定性。缺点：在低活动期间（99% 的时间）浪费大量内存，违反了协同服务器的内存限制，并且无法处理超出容量的黑天鹅事件。
解决方案 2：切换到 std::list 用 std::list 替换向量以消除重新分配的需求。优点：天然保证强异常安全性，迭代器稳定。缺点：缓存局部性被破坏（迭代速度变慢 5-10 倍），每个节点的内存开销（额外 16-24 字节），造成多线程环境中的分配器争用。
解决方案 3：强制 noexcept 移动语义 重构所有快照类型以使用 std::unique_ptr 处理堆资源，并明确标记移动构造函数为 noexcept。优点：实现快速移动（比复制快 80%），保持强异常安全性，兼容标准容器。缺点：需要严格的代码审查以确保在移动路径中没有抛出操作，对类设计的限制（在移动中不能使用抛出资源的获取）。
选择的解决方案：我们选择了 解决方案 3，并进行了代码基审计，以使所有关键数据结构都符合 noexcept-movable。我们添加了静态断言（使用 static_assert(std::is_nothrow_move_constructible_v<Data>)）以防止回归。
结果：在市场峰值期间，延迟降低了 42%，并且在注入异常的压力测试中保持零损坏事件。该系统通过了对异常安全性要求的监管审计。
为什么 std::vector 特别要求在重新分配期间提供强异常安全性而不是基本保证？
基本异常安全性只要求程序保持有效状态而不发生资源泄漏，允许容器处于部分移动状态。然而，从用户的角度来看，重新分配是一个原子操作—缓冲区指针要么改变，要么不变。如果 std::vector 仅提供基本安全性，异常可能会导致容器的一些元素在旧内存中，而一些在新内存中，或者出现不一致的大小/容量计数，从而违反类不变式并导致后续操作的未定义行为。强保证确保事务语义：要么增长完全成功，要么向量保持完全不变。
编译器如何优化对 noexcept 移动构造函数的检查而不引入运行时开销？
std::vector 利用 std::is_nothrow_move_constructible<T>，这是一种编译时特征。实现通常使用 std::move_if_noexcept，这是一个函数模板，如果移动构造函数可能抛出，则返回一个左值引用（触发复制），否则返回一个右值引用（触发移动）。这种调度在编译时通过函数重载和模板实例化进行，生成最佳代码路径，而没有运行时分支。如果移动被证明为 noexcept，编译器可以完全消除备用复制路径，从而实现零成本抽象。
如果一个类型是仅移动（不可复制的），而它的移动构造函数不是 noexcept，会发生什么？
如果像 std::unique_ptr （仅移动）这样的类型有一个抛出移动构造函数（假设），std::vector 面临一个不可能的选择：它无法复制（类型不可复制），也无法安全移动（可能抛出）。在 C++17 之前，这会导致需要重新分配的操作编译错误。自 C++17 以来，标准规定 std::vector 将使用抛出移动，但仅提供 基本异常安全性—如果移动抛出，元素可能会丢失或容器保持在未指定的有效状态。这就是为什么标准库中的所有仅移动类型（如 std::unique_ptr、std::fstream）都保证 noexcept 移动，以及为什么自定义仅移动类型也应遵循相同的原因。