std::is_nothrow_move_constructible 影响 vector 扩容策略：若为 true 则直接移动元素并保证强异常安全，否则退化为复制+析构，导致性能下降和异常后状态不确定；需显式声明且实现 noexcept，成员与基类也须满足。
std::is_nothrow_move_constructible 影响 vector 扩容时的异常安全策略
当 std::vector 需要扩容（比如调用 push_back 触发重新分配），它必须把旧元素搬进新内存。如果元素类型支持无异常移动构造（即 std::is_nothrow_move_constructible_v<t></t> 为 true），vector 就直接移动；否则退回到“复制 + 析构”老元素的保守路径——这不仅慢，还可能在复制中途抛异常导致部分元素丢失。
常见错误现象：自定义类没声明 noexcept 移动构造函数，结果 vector 扩容时性能骤降、且异常发生后容器处于不确定状态。
- 移动构造函数必须显式标记
noexcept（仅声明不够，得实现也满足） - 成员变量和基类的移动构造也得是
noexcept，否则编译器推导出的std::is_nothrow_move_constructible_v<t></t>仍为false - 用
static_assert(std::is_nothrow_move_constructible_v<mytype>, "…");</mytype>在编译期卡住问题
如何验证你的类型是否被 vector 当作 nothrow 可移动
别只看有没有移动构造函数——std::vector 内部依赖 std::is_nothrow_move_constructible 的特化结果，而这个 trait 是编译器根据函数签名（含 noexcept 说明符）静态判断的，不运行时不暴露。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 写个最小测试类，带移动构造但不加
noexcept，然后static_assert(!std::is_nothrow_move_constructible_v<myclass>);</myclass>确认失败 - 加上
MyClass(MyClass&&) noexcept后再 assert，应通过 - 用
g++ -std=c++17 -fno-exceptions编译时注意：此时所有函数默认noexcept(true)，但标准库 trait 仍按有异常语义推导，不可依赖该编译选项“绕过”检查
vector 扩容时 move vs copy 的实际性能差距
差别不止在“快一点”——移动路径避免了深拷贝开销，更重要的是它让 vector 能在异常发生时保持强异常安全：要么全搬完，要么原地不动。复制路径做不到这点。
典型场景：一个含 std::string 和 std::vector<int></int> 的结构体，若未标记 noexcept 移动构造，vector 扩容时会逐个复制字符串缓冲区，而不是交换指针。
- 用
valgrind --tool=callgrind或 perf 对比扩容前后 cache miss 次数，能明显看到复制路径触发更多内存分配和 memcpy - 即使你不用异常，标准库仍按规范走不同分支——这不是优化开关，是行为契约
-
std::deque和std::list不受此影响（它们不连续存储、不整体搬迁），但std::vector和std::string（内部也是动态数组）直接受控
容易被忽略的隐式 noexcept 陷阱
移动构造函数是否 noexcept，不是看它“实际会不会抛”，而是看它“声明会不会抛”。哪怕函数体空着，没写 noexcept 就算可能抛。
更隐蔽的情况：
- 类中有
std::function成员：它的移动构造是noexcept，但若你手动写了移动构造却忘了加noexcept，整个类就“掉出”nothrow 移动集合 - 继承链中某基类移动构造非
noexcept，派生类即使写了noexcept移动构造，也会因基类调用而被编译器判为可能抛异常 - 模板类实例化时，
std::is_nothrow_move_constructible_v对每个T单独求值——std::vector<:string></:string>是 nothrow 可移动的，但std::vector<mybadclass></mybadclass>不是，这点在泛型代码里极易漏检
真正关键的不是“能不能写 noexcept”，而是“编译器信不信你”。一旦不信，vector 就退回复制，而且这个决策发生在编译期，运行时无法补救。
