为何并非所有标准容器都具备noexcept移动构造特性？

• 分配器兼容性是核心障碍
  移动赋值在C++17后能标记noexcept，前提是分配器相等且满足约束——这是因为目标对象已经持有一个分配器，当和源对象分配器相等时，可以直接接管源的资源，无需新的内存分配。但移动构造的场景里，新对象的分配器是默认构造或用户显式指定的，完全可能和源对象的分配器不相等。对于不支持跨分配器资源转移的容器（比如多数关联容器），此时只能重新分配内存并复制元素，这个过程必然可能抛出异常，因此无法统一标记noexcept。

• 容器设计的历史与现实约束
  早期C标准对移动操作的异常保证设计相对宽松，C17针对移动赋值做了优化，但移动构造的场景更复杂：新对象的初始化过程中，分配器的兼容性检查和资源转移逻辑比赋值场景更繁琐。比如std::map这类容器的节点内存由分配器管理，若分配器不兼容，移动构造只能退化为拷贝构造的逻辑，涉及内存分配，自然无法保证不抛出异常。

• 并非“错误保持源对象状态”
  你提到的“保持源对象超出要求的状态”其实不是主要原因，真正的问题在于分配器模型的约束：当分配器不相等时，容器无法将源对象的内存直接转移给新对象，必须重新分配内存来容纳元素——这不是实现上的“错误”，而是标准分配器模型下的必然结果。标准只要求被移动后的对象处于可析构、可赋值状态，但分配器不兼容时，容器根本做不到无分配的资源转移。

内容的提问来源于stack exchange，提问作者Valentin Milea