std::vector扩容时必须检查std::is_nothrow_move_constructible_v，因为标准要求强异常安全：若移动构造可能抛异常，则必须用拷贝路径避免状态损坏，导致内存峰值翻倍和O(n)深拷贝。
不满足 std::is_nothrow_move_constructible_v 的类型，std::vector 扩容时一定会走拷贝路径，性能可能直接腰斩，且异常后状态不可靠——这不是可选优化，是标准强制行为。
为什么 vector 扩容时必须检查这个 trait
扩容本质是“在新内存中重建元素 + 清理旧内存”。标准要求 push_back 等操作提供强异常安全：失败时容器必须和调用前完全一致。如果移动构造可能抛异常（哪怕概率极低），vector 就不敢直接移动——因为中途失败会导致旧对象已被析构、新对象只建了一半，状态彻底损坏。
此时唯一安全的做法是：先在新内存里完整拷贝所有元素，全部成功后再批量析构旧对象。这带来两个硬伤：
- 内存峰值翻倍（新旧两份数据共存）
- 时间开销从 O(1) 移动变成 O(n) 深拷贝（比如
std::string复制缓冲区，而非交换指针）
如何验证你的类型是否真正满足
别信直觉，也别只看有没有移动构造函数。编译器只认签名里的 noexcept 说明符，且会递归检查整条链路：
立即学习“C++免费学习笔记（深入）”；
-
static_assert(std::is_nothrow_move_constructible_v<myclass>, "…");</myclass>是最直接的卡点方式 - 即使写了
MyClass(MyClass&&)，没加noexcept→ trait 为false - 成员含
std::mutex、未标记noexcept的自定义资源类、或基类移动构造没noexcept→ 整个类 trait 仍为false - 使用
std::pmr::string或带状态分配器时，construct()可能抛std::bad_alloc→ trait 失效
修复的关键动作只有三步
缺一不可：
- 显式给移动构造函数加上
noexcept（不是noexcept(true)，后者冗余） - 确保函数体内所有操作都不抛异常：成员移动必须也满足
noexcept，不能调用new、std::mutex::lock()等 - 若类型有基类或组合成员，逐层检查它们的
std::is_nothrow_move_constructible_v是否为true
漏掉任意一层，trait 就是 false，vector 就会降级。
reserve() 和 std::move_iterator 都绕不过去
很多人误以为提前 reserve() 就能避免问题——其实它只预分配内存，不触发元素搬迁；真正决定走哪条路径的是扩容时的 reallocate() 步骤，而该步骤完全依赖 std::is_nothrow_move_constructible_v 的编译期结果。
同理，std::move_iterator 只是包装迭代器，底层仍由 vector 内部逻辑根据 trait 判断能否安全移动。trait 不满足，它照样退回到拷贝。
最隐蔽的点在于：即使你项目里完全不用 try/catch，标准库依然按规范执行不同分支——这不是运行时开关，是编译期契约。
