noexcept 是 std::vector 扩容时启用移动语义的必要条件：仅当元素类型满足 std::is_nothrow_move_constructible_v 时，vector 才直接移动而非复制；否则退回到复制+析构，导致深拷贝开销。

noexcept 对 std::vector 扩容时的移动行为起决定性作用

当 std::vector 需要扩容（比如调用 push_back 触发重新分配），它必须把旧内存中的元素搬移到新内存。如果元素类型声明了 noexcept 移动构造函数，vector 就敢直接移动；否则，它会退回到更保守的“复制 + 析构”路径——哪怕你写了移动构造函数，只要没标 noexcept，它大概率不用。

• 标准明确要求：只有当 T 的移动构造函数是 noexcept 时，std::vector 的扩容才允许使用移动语义
• 反例：std::vector<:string> 在大多数实现中能高效移动，因为 std::string 的移动构造是 noexcept；而自定义类若漏掉 noexcept，即使逻辑上不抛异常，vector 也会复制
• 验证方式：可检查 std::is_nothrow_move_constructible_v，这是容器内部实际依赖的 trait

不加 noexcept 的移动构造函数在容器中可能完全失效

这不是性能打折的问题，而是行为降级：移动语义被静默绕过。尤其在持有大对象（如缓冲区、句柄）的类中，复制可能触发深拷贝或系统调用，开销陡增。

• 常见误写：T(T&& other) { /* ... */ } —— 缺少 noexcept，编译器默认视为可能抛异常
• 正确写法：T(T&& other) noexcept { /* ... */ }，且确保函数体里所有操作（包括成员移动、析构调用）都不抛异常
• 若某成员移

  

  动构造本身不是 noexcept（比如用了可能抛异常的 new），整个类的移动构造就无法安全标 noexcept，需重构或接受复制代价

如何判断你的类是否满足容器优化条件

不能只看自己写了 noexcept，还要看所有子对象和基类是否真正支持。

• 用 static_assert 快速验证：

  static_assert(std::is_nothrow_move_constructible_v, "MyClass must be nothrow move constructible for vector efficiency");

• 注意继承：若基类移动构造未标 noexcept，派生类即使写了 noexcept 也可能因隐式调用基类而违反约束
• 编译器不会警告你“这里本该用移动却用了复制”，只能靠 is_nothrow_move_constructible_v 或观察扩容时的拷贝计数器来发现

关键点在于：noexcept 不是可选修饰，它是移动语义进入标准容器底层路径的通行证。漏掉它，等于把优化锁死在门外。