std::is_nothrow_move_constructible 是编译期断言，用于判断类型移动构造是否可能抛异常；它影响容器扩容时选择移动还是拷贝路径，需显式声明并定义 noexcept 移动构造函数以确保满足该特性。
std::is_nothrow_move_constructible 是什么，什么时候需要它
它不是性能优化的开关，而是移动构造是否可能抛异常的编译期断言。真正影响性能的是 std::vector、std::deque 等容器在扩容时的策略选择：如果元素类型满足 std::is_nothrow_move_constructible_v<t></t>，容器会优先用移动而非拷贝来重排内存；否则退回到更保守（但安全）的拷贝路径。
换句话说，你写不出“更快的移动”，但能避免被强制降级为慢得多的拷贝——尤其对大对象或资源密集型类型。
怎么确认你的类型是否被识别为 nothrow move constructible
别靠猜，直接静态断言：
static_assert(std::is_nothrow_move_constructible_v<mytype>, "MyType must be nothrow move constructible");</mytype>
常见误判点：
- 只要移动构造函数声明了
noexcept（哪怕函数体里写了可能抛异常的代码），编译器就信你——但运行时崩溃风险由你承担 - 若没显式定义移动构造函数，编译器生成的默认版本是否
noexcept，取决于其所有成员和基类是否都满足std::is_nothrow_move_constructible - 含
std::string、std::vector等标准容器的类，通常自动满足（C++11 起这些容器的移动构造已标记noexcept）
手动标记 noexcept 时容易踩的坑
最典型错误是只给声明加 noexcept，却忘了定义也得同步：
struct BadExample {
BadExample(BadExample&&) noexcept; // 声明有 noexcept
}; // 定义在别处？没写 noexcept → 实际不满足 is_nothrow_move_constructible
正确写法必须一致：
struct GoodExample {
GoodExample(GoodExample&&) noexcept = default; // 或
GoodExample(GoodExample&& other) noexcept
: data(std::move(other.data)) {} // 定义里也带 noexcept
};
另一个陷阱：调用了可能抛异常的函数（比如未加 noexcept 的自定义移动辅助函数），会导致整个移动构造函数隐式失去 noexcept 属性，即使你写了 noexcept 也会被编译器忽略。
它和 std::move 的关系经常被误解
std::move 本身不抛异常，也不保证目标类型能无异常移动；它只是把左值转成右值引用。真正决定能否走无异常移动路径的，是类型本身的 std::is_nothrow_move_constructible 特性 + 容器/算法的内部逻辑。
所以别以为用了 std::move 就自动高效——如果 T 不满足该 trait，std::vector::push_back(std::move(x)) 在扩容时仍可能触发拷贝，而不是你预期的移动。
真正关键的是：确保移动构造函数存在、被选中、且标记为 noexcept；其余交给标准库容器自己判断。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
