noexcept 是 std::vector 扩容时启用移动语义的必要条件：仅当元素类型满足 std::is_nothrow_move_constructible_v 时，vector 才直接移动而非复制；否则退回到复制+析构，导致深拷贝开销。
noexcept 对 std::vector 扩容时的移动行为起决定性作用
当 std::vector 需要扩容（比如调用 push_back 触发重新分配），它必须把旧内存中的元素搬移到新内存。如果元素类型声明了 noexcept 移动构造函数，vector 就敢直接移动；否则，它会退回到更保守的“复制 + 析构”路径——哪怕你写了移动构造函数，只要没标 noexcept，它大概率不用。
- 标准明确要求：只有当
T的移动构造函数是noexcept时，std::vector<t></t>的扩容才允许使用移动语义 - 反例：
std::vector<:string></:string>在大多数实现中能高效移动，因为std::string的移动构造是noexcept；而自定义类若漏掉noexcept，即使逻辑上不抛异常，vector也会复制 - 验证方式：可检查
std::is_nothrow_move_constructible_v<t></t>，这是容器内部实际依赖的 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>, "MyClass must be nothrow move constructible for vector efficiency");
- 注意继承：若基类移动构造未标
noexcept，派生类即使写了noexcept也可能因隐式调用基类而违反约束 - 编译器不会警告你“这里本该用移动却用了复制”，只能靠
is_nothrow_move_constructible_v或观察扩容时的拷贝计数器来发现
关键点在于：noexcept 不是可选修饰，它是移动语义进入标准容器底层路径的通行证。漏掉它，等于把优化锁死在门外。
立即学习“C++免费学习笔记（深入）”；
