vector扩容是否走移动路径由std::is_nothrow_move_constructible_v编译期决定；若为false则强制深拷贝，导致性能断崖下跌，因其需保证强异常安全。
std::vector 扩容时是否走移动路径，完全由 std::is_nothrow_move_constructible_v 编译期判定决定；没标 noexcept 的移动构造函数，哪怕只有一行赋值，也会让这个 trait 为 false，强制退化为深拷贝——这不是慢一点，是性能断崖下跌。
为什么 vector 扩容必须依赖 std::is_nothrow_move_constructible_v
扩容本质是内存重分配：申请新内存 → 搬移旧元素 → 销毁旧对象。若搬移过程（即移动构造）可能抛异常，就无法保证强异常安全——中途失败会导致部分元素已搬、部分未搬、旧内存已被释放，状态彻底损坏。
标准库因此强制分叉：
- 若
std::is_nothrow_move_constructible_v<t></t>为 true：直接调用T(T&&)移动每个元素，再析构原对象；开销接近 O(1)，资源窃取即可 - 若为 false：先在新内存中逐个调用
T(const T&)拷贝，全部成功后再析构旧对象；触发多次堆分配、memcpy、析构链式调用
注意：vector 不会“尝试”移动再 fallback；它全信这个 trait，且判断在编译期完成，无运行时开销。
立即学习“C++免费学习笔记（深入）”；
如何让自定义类真正满足 std::is_nothrow_move_constructible_v
不是“写了移动构造函数”就行，关键是让编译器静态确认它绝不会抛异常。以下要点缺一不可：
- 移动构造函数声明末尾必须显式写
noexcept，不能省略，不能写成noexcept(true)或空括号 - 所有数据成员的移动构造函数也必须满足
std::is_nothrow_move_constructible_v（例如std::string在 C++11+ 默认满足，但std::pmr::string可能不满足） - 基类的移动构造函数同样需为
noexcept；派生类即使手动写了移动构造，若基类没标，整个 trait 仍为 false - 含
std::mutex、std::thread或未标记noexcept的自定义 RAII 成员？该类天然不满足，硬标noexcept是未定义行为
错误示范：MyClass(MyClass&& other) { data_ = std::move(other.data_); } —— 即使函数体完全安全，trait 仍是 false。
用 static_assert 在编译期卡住问题
别等上线后发现 push_back 变慢十倍。把校验放在类定义后或容器使用前：
class Widget {
public:
Widget(Widget&& other) noexcept : data_(std::move(other.data_)) {
other.data_ = nullptr;
}
private:
std::unique_ptr<int> data_;
};
static_assert(std::is_nothrow_move_constructible_v<Widget>, "Widget must be nothrow move constructible");
若编译失败，说明你标错了——要么函数体里藏了潜在异常点（如调用了未标记 noexcept 的成员函数），要么某个成员本身不满足 trait。此时应逐个注释成员，定位传染源。
配合 reserve 彻底消除隐式扩容路径
即使类型满足 std::is_nothrow_move_constructible_v，频繁小步扩容仍引发多次内存分配与移动。建议：
- 预估容量，在插入前调用
vec.reserve(N) - reserve 前加校验：
static_assert(std::is_nothrow_move_constructible_v<T>)，避免 reserve 内部因 trait 失败而意外走拷贝分支 - 注意：
std::is_nothrow_move_assignable_v<T>也要成立，因为push_back末尾插入可能用到移动赋值
最易被忽略的是：lambda 捕获或 std::function 存储的对象，其移动是否 noexcept 取决于所存可调用对象，这类间接依赖很难靠肉眼发现，必须靠 static_assert 覆盖。
