std::is_nothrow_move_constructible 在 vector 扩容时决定是否启用移动而非拷贝来搬移元素：仅当该 trait 与 noexcept 移动赋值同时满足时，vector 才选择移动路径以避免深拷贝开销和异常回滚，否则退回到拷贝路径。
std::is_nothrow_move_constructible 在 vector 扩容时起什么作用？
它不直接“优化”代码，而是让 std::vector 决定是否能安全地用移动而非拷贝来搬移老元素。当 T 满足 std::is_nothrow_move_constructible_v<t></t> 且其移动赋值也 noexcept 时，std::vector::resize 或 push_back 触发扩容时，会选移动路径——避免深拷贝开销，也不触发异常回滚逻辑。
常见错误现象：明明写了移动构造函数，但 vector 扩容仍调用拷贝构造。原因往往是移动构造没加 noexcept，导致 std::is_nothrow_move_constructible_v<t></t> 为 false。
- 移动构造函数必须显式标注
noexcept（编译器不会自动推导） - 类中若含非
noexcept成员（如std::string在旧标准下可能抛异常），整个类型就不是noexcept可移动的 -
std::vector的扩容策略依赖这个 trait；否则退回到拷贝 + 异常安全回滚路径，性能差且可能意外调用拷贝
怎么验证你的类型是否被 vector 当作 nothrow 可移动？
别猜，写个最小测试：
static_assert(std::is_nothrow_move_constructible_v<MyType>, "MyType must be noexcept move constructible"); static_assert(std::is_nothrow_move_assignable_v<MyType>, "also need noexcept move assign");
如果断言失败，说明 std::vector 扩容时不会用移动。典型场景是自定义类含裸指针或小对象，但忘了给移动操作加 noexcept。
立即学习“C++免费学习笔记（深入）”；
-
std::is_nothrow_move_constructible只检查构造，不检查析构或赋值；而 vector 实际需要两者都noexcept -
std::string、std::vector等标准容器在 C++11 后基本都满足（取决于实现），但早期 libstdc++ 对std::string的移动可能未标记noexcept - 用
clang++ -std=c++17或更高版本 + libc++ 更容易获得一致行为
手动控制扩容路径：move_if_noexcept 的实际意义
std::move_if_noexcept 是 std::vector 内部使用的工具函数，它不是让你调用的 API，而是提醒你：vector 是否走移动路径，完全取决于类型 trait 和编译器对 noexcept 的判断。
你无法绕过这个机制去“强制移动”，因为：
- 如果类型不满足
noexcept移动条件，强行移动可能导致异常后状态不一致 -
std::vector的异常安全保证（强保证）依赖于：要么全拷贝成功，要么原容器不变。移动只有在确定不会抛异常时才启用
所以真正要做的，是让类型“达标”：
- 所有成员的移动操作都
noexcept - 自己的移动构造/赋值函数显式写
noexcept - 避免在移动操作里做可能抛异常的事（如 new、文件 IO、锁操作）
性能差异有多大？什么时候值得较真？
对小对象（如 int、std::unique_ptr），差异几乎为零；但对持有大缓冲区的类型（如自定义 string、matrix、buffer wrapper），一次扩容从拷贝变移动，可省掉 O(n) 内存分配和 memcpy。
容易踩的坑：
- 把
noexcept加在声明上，但定义在 cpp 文件里没重复写，链接期 trait 判定失效 - 使用
auto推导返回类型时，移动操作被隐式转成拷贝（尤其 lambda 捕获值时） - 在模板中泛化使用，没约束
noexcept要求，导致特化类型意外降级为拷贝路径
真正难的是让整个类型链上的所有移动操作都稳定 noexcept——包括基类、成员、模板参数。漏一个，std::vector 就退回保守方案。
