std::vector扩容时是否调用移动构造函数由std::is_nothrow_move_constructible_v决定：为true则安全移动，false则回退到拷贝构造；关键在于移动构造函数必须显式声明noexcept，否则性能腰斩且异常状态不可靠。
不满足 std::is_nothrow_move_constructible_v，std::vector 扩容时必然回退到拷贝构造，性能直接腰斩，且异常后状态不可靠——这不是优化建议，是标准强制行为。
vector 扩容时 move 和 copy 的切换逻辑由它决定
扩容触发重分配（如 push_back 超出 capacity()）时，std::vector 不会“尝试移动”，而是静态检查 std::is_nothrow_move_constructible_v<t></t>：
- 为
true：逐个调用T(T&&) noexcept移动旧元素，随后析构原对象； - 为
false：先在新内存中逐个copy-construct所有元素，全部成功后再逐个析构旧对象。
关键不是“能不能写移动构造函数”，而是“它是否被声明为 noexcept”。哪怕函数体里只有一行 data_ = nullptr;，没写 noexcept，trait 就是 false。
自定义类型漏写 noexcept 是最常见性能坑
你写了移动构造函数，但忘了加 noexcept，结果 std::vector<myclass></myclass> 在插入第 10001 个元素时突然变慢两倍、内存峰值翻倍——这就是典型表现。
立即学习“C++免费学习笔记（深入）”；
- 正确写法：
MyClass(MyClass&& other) noexcept : data_(other.data_) { other.data_ = nullptr; } - 错误写法：
MyClass(MyClass&& other) { data_ = other.data_; other.data_ = nullptr; }（即使函数体完全安全） -
= default也不行：MyClass(MyClass&&) = default;不等价于noexcept；必须显式写MyClass(MyClass&&) noexcept = default;
别依赖编译器推导：C++ 标准规定，未标注 noexcept 的函数默认视为“可能抛异常”，trait 结果与实现无关。
成员、基类、分配器都会拖垮整个 trait
std::is_nothrow_move_constructible_v<t></t> 是全链路静态判断。只要任意一环不满足，结果就是 false：
- 成员变量含
std::mutex或未标记noexcept的自定义类型（如NonNothrowResource）； - 基类的移动构造函数没加
noexcept，派生类即使手动写了也无效； - 用了自定义分配器（如
std::pmr::string），而该分配器的construct()可能抛std::bad_alloc； - 成员是
std::vector<:string></:string>：虽然std::string本身通常满足，但某些 libstdc++ 旧版本或带状态分配器时可能不满足。
验证不能只看声明——用 static_assert 卡住编译：
static_assert(std::is_nothrow_move_constructible_v<MyClass>, "MyClass must be nothrow move constructible for vector growth");
别指望 reserve() 或 move_iterator 绕过这个约束
reserve() 只预分配内存，不触发元素搬迁；真正决定走哪条路径的是扩容时的 reallocate() 步骤。哪怕你 reserve(100000)，只要下一次 push_back() 导致容量突破，trait 检查就立刻生效。
-
std::move_iterator无法绕过：它只是把迭代器包装成“可移动语义”，底层仍依赖std::is_nothrow_move_constructible决定能否安全调用移动构造； - 某些 STL 实现（如 libstdc++）在满足
noexcept+trivially_destructible时还会进一步启用memmove位拷贝优化，但这属于额外红利，基础门槛仍是这个 trait； - 第三方类型（如
absl::string_view或嵌入式 STL）不保证满足，跨平台项目务必显式static_assert。
最隐蔽的问题在于：它不报错、不警告，只默默变慢、多占内存、异常后状态损坏——直到压测或线上 OOM 才暴露。
