std::is_nothrow_move_constructible<T>::value为true时，std::vector扩容直接移动元素；否则退回到复制路径，影响性能与异常安全性。
一、理解 std::is_nothrow_move_constructible 的语义作用
当类型 T 被用于容器扩容（如 std::vector 在 reserve 或 resize 过程中重新分配内存）时，若其移动构造函数被标记为 noexcept，则标准库可安全启用移动而非复制，从而避免冗余深拷贝开销。该特性直接影响容器重分配期间的异常安全性与性能路径选择。
1、std::is_nothrow_move_constructible
2、若该 trait 为 false，std::vector 在增长容量时将退回到复制元素路径，即使 T 定义了移动构造函数。
3、该 trait 不检测移动构造函数是否存在，只检测其是否为 nothrow；未定义移动构造函数的类型默认 fallback 到拷贝构造函数，并依据拷贝构造是否 noexcept 决定结果。
立即学习“C++免费学习笔记（深入）”；
二、验证类型是否满足 nothrow 移动构造条件
编译期断言是识别类型在扩容上下文中行为的关键手段，可提前暴露因异常规范缺失导致的性能回退问题。
1、使用 static_assert 强制校验：
static_assert(std::is_nothrow_move_constructible_v<:string>, "string must be nothrow move constructible");
2、对自定义类，确保移动构造函数显式标注 noexcept：
MyClass(MyClass&& other) noexcept : data_(other.data_) { other.data_ = nullptr; }
3、若成员变量或基类的移动构造函数非 noexcept，则整个类的移动构造函数自动变为可能抛异常，trait 返回 false。
三、std::vector 扩容时的 trait 实际影响路径
std::vector 在调用 resize、reserve 或插入引发重分配时，依据元素类型的 is_nothrow_move_constructible 状态选择元素迁移策略：true 则直接移动，false 则尝试复制（若复制也不 noexcept，则可能触发强异常安全保证下的额外临时缓冲区分配）。
1、当 vector
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
2、当该 trait 为 false 但 std::is_copy_constructible_v
3、若 T 既不满足 nothrow 移动构造，也不满足复制构造，则扩容操作可能编译失败或触发未定义行为。
四、修复非 nothrow 移动构造类型的常见方式
使自定义类型适配高效扩容需从异常规范与成员设计两方面入手，确保移动构造路径稳定且无异常出口。
1、为移动构造函数添加 noexcept 说明符，前提是所有数据成员的移动构造及析构均不抛异常。
2、将可能抛异常的资源获取操作移出移动构造函数，例如延迟到后续赋值或初始化列表外处理。
3、若某成员类型（如 std::mutex）不可移动或其移动构造非 noexcept，考虑将其改为指针托管（std::unique_ptr）或使用 const 成员规避移动。
4、禁用移动构造函数（= delete）后，trait 自动降级为检查拷贝构造是否 noexcept；此时应同步确保拷贝构造为 noexcept 或接受性能损失。
五、编译器与标准库实现差异带来的注意事项
不同标准库实现（libstdc++、libc++、MSVC STL）对 is_nothrow_move_constructible 的依赖程度和 fallback 行为存在细微差别，尤其在 C++11 与 C++17 后的优化策略中。
1、C++17 起，std::vector::resize 和 push_back 的强异常安全要求已放宽，更积极采用移动路径，但前提仍是 trait 为 true。
2、libstdc++ 在 -D_GLIBCXX_CONCEPTS=1 下会进行更严格的 trait 检查，而默认配置下可能忽略部分边界情形。
3、Clang + libc++ 在调试模式下会对 trait 不满足的情况发出警告，GCC 默认不提示，需依赖 -D_GLIBCXX_DEBUG 编译。
