标准库容器（如std::vector）扩容时，不加noexcept的移动构造函数不会被调用，而是强制退化为拷贝构造，这是标准强制要求而非编译器优化；因未声明noexcept则视为可能抛异常，为保障强异常安全，容器必须改用拷贝以避免部分移动导致状态不可恢复。
标准库容器（比如 std::vector）在扩容时，**不加 noexcept 的移动构造函数根本不会被调用**——它会直接退化成拷贝构造，性能可能差几倍。这不是编译器优化选择，而是标准强制要求的行为。
std::vector 扩容时为什么只信任 noexcept 移动
当 std::vector 需要重新分配内存，它得把老元素搬到新空间。这时它面临一个安全抉择：
- 如果移动构造函数声明了
noexcept，说明“搬这个对象绝不会出异常”，那就可以放心逐个移动，失败风险为零 - 如果没声明
noexcept，编译器无法排除它抛异常的可能：万一搬了一半出错，旧内存里部分对象已被掏空、新内存里只有一半有效，整个容器就处于不可恢复的中间态 - 为保强异常安全（strong exception safety），
std::vector只能退而求其次，用拷贝构造——即使失败，老数据完好无损，新拷贝可直接丢弃
哪些 STL 操作实际依赖 noexcept 移动
不只是 push_back 触发的扩容，以下操作在内部做元素重排或转移时，都会检查移动构造是否 noexcept：
-
std::vector::reserve()和resize() -
std::deque::shrink_to_fit()（部分实现） -
std::make_heap()、std::sort()等算法对容器内元素做原地重排时，若底层使用移动而非交换，也会受此约束 -
std::unordered_map重新哈希（rehash）时迁移桶中元素
noexcept 不是“可选优化”，而是契约的一部分
声明 noexcept 不只是告诉编译器“我不抛异常”，更是向标准库承诺：“你可以无条件信任我的移动操作”。一旦违反这个承诺（比如在 noexcept 函数里写了 throw），程序会直接调用 std::terminate() 终止，没有栈展开、没有日志、没有挽救机会。
常见踩坑点：
- 移动构造函数体里调用了可能抛异常的函数（如未加
noexcept的成员函数、new分配失败未捕获） - 误以为
std::move(x)本身会抛异常——其实它只是类型转换，真正抛异常的是被调用的移动构造/赋值函数 - 只给移动构造加
noexcept，却忘了移动赋值运算符（operator=），导致std::vector::assign()等操作仍退化为拷贝 - 继承类中重写移动构造时，没显式加上
noexcept，哪怕基类已声明——C++ 不自动继承异常规范
最常被忽略的一点：即使你从不手动抛异常，只要任何被调用的函数（包括成员变量的移动操作）没标记 noexcept，整个链路就失去 noexcept 保证。比如 std::vector<t></t> 的移动构造是 noexcept 的，但前提是 T 的移动构造也是 noexcept ——否则它自己也会退化成拷贝。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
