std::is_nothrow_move_constructible 用于判断类型是否支持不抛异常的移动构造，仅在模板元编程中影响标准库容器（如 std::vector）的移动/拷贝决策，本身不优化性能也不改变行为。
std::is_nothrow_move_constructible 是什么，什么时候必须用它
它不是用来“优化性能”的开关，而是用来判断类型是否支持 不抛异常的移动构造 —— 这个信息只在模板元编程中才有实际意义，比如 std::vector 在扩容时决定要不要用移动而非拷贝，前提是移动构造函数被标记为 noexcept，且类型满足 std::is_nothrow_move_constructible_v<t></t>。
常见错误是以为加了这个 trait 就能让移动变快，其实它本身不生成任何代码，也不改变行为；它只是让编译器/标准库能做更安全的决策。
- 如果你的类移动构造函数没声明
noexcept，即使内部不抛异常，std::is_nothrow_move_constructible_v<t></t>也会返回false - 如果移动构造函数里调用了可能抛异常的函数（比如
new、std::string的移动构造在某些实现中可能抛），那它就不是noexcept，trait 自然为false -
std::vector在resize或push_back触发重新分配时，若元素类型不满足该 trait，会退回到拷贝构造（更慢且要求T可拷贝）
怎么让自己的类型真正满足 std::is_nothrow_move_constructible
关键不是查 trait，而是确保移动构造函数被正确声明为 noexcept，且所有成员/基类的移动构造也满足该条件。
示例：
立即学习“C++免费学习笔记（深入）”；
struct A {
std::string s;
int* p;
A(A&& other) noexcept : s(std::move(other.s)), p(other.p) {
other.p = nullptr;
}
};这里 A 能通过 std::is_nothrow_move_constructible_v<a></a>，是因为：std::string 的移动构造在 C++11 后被要求为 noexcept（实际取决于标准库实现，但主流 libstdc++/libc++ 都满足），int* 的移动就是简单赋值，天然不抛。
- 手动写移动构造时，必须显式加
noexcept，编译器不会自动推导 - 若成员中有自定义类型
B，要确认std::is_nothrow_move_constructible_v<b></b>为true，否则整个类型不满足 - 使用
= default生成移动构造时，编译器会按成员是否都noexcept自动决定是否给函数加上noexcept—— 所以优先用= default，但得检查结果
如何验证和调试不满足的情况
最直接的方式是静态断言 + 编译期检查：
static_assert(std::is_nothrow_move_constructible_v<A>, "A must be nothrow move constructible");
如果断言失败，错误信息会提示哪一层出了问题。常见源头包括：
- 某个成员类型（如自定义容器）的移动构造没加
noexcept - 基类的移动构造函数不是
noexcept - 误把
std::move用在了不支持移动的类型上（比如内置数组），导致退化为拷贝，而拷贝构造可能未声明noexcept - 用了
std::vector但元素类型不满足该 trait，运行时不会报错，但性能下降且无法触发移动优化路径
std::is_nothrow_move_constructible 在标准库中的真实影响点
它不直接影响你写的代码逻辑，但会改变标准容器的行为边界。例如：
-
std::vector::resize(n)：若T满足该 trait，新元素用移动构造（从旧内存搬移）；否则用拷贝构造（要求T可拷贝） -
std::vector::reserve()不涉及构造，所以不受影响 -
std::deque和std::list对移动异常性不敏感，它们的重分配策略不同 -
std::optional<t></t>在就地构造或交换时，也会依赖该 trait 决定是否允许异常传播
真正容易被忽略的是：即使你写了 noexcept 移动构造，只要任意一个间接依赖的类型（比如模板参数、成员类型）不满足，整个链就断掉 —— 这种问题往往只在集成测试或特定 STL 实现下暴露。
