std::is_nothrow_move_constructible 是一个编译期类型特征，用于判断类型 T 的移动构造函数是否被显式声明为 noexcept；它仅作查询不改变行为，且需与 std::is_nothrow_move_assignable 一同为 true，才能使 std::vector 等容器在扩容时安全启用移动而非拷贝。
std::is_nothrow_move_constructible 是什么，它能保证什么
它只是个类型特征（type trait），用于在编译期判断某个类型 T 的移动构造函数是否被声明为 noexcept。它不“确保”任何运行时行为，也不自动让移动构造变 noexcept —— 它只告诉你：如果 T 的移动构造函数确实标记了 noexcept，那 std::is_nothrow_move_constructible_v<t></t> 就是 true；否则就是 false。
常见误解是以为用了这个 trait 就能“启用强异常安全”，其实它只是强异常安全的前提之一。真正起作用的是你是否把移动操作显式声明为 noexcept，以及标准库容器（如 std::vector）是否据此选择移动而非拷贝。
为什么 vector::resize 或 push_back 会依赖这个 trait
当 std::vector 需要重新分配内存（比如扩容），它会尝试移动已有元素。但如果元素类型不满足 std::is_nothrow_move_constructible，标准库就退回到拷贝构造——因为一旦移动构造中途抛异常，原容器状态已破坏（部分移动、部分未动），无法回滚，违反强异常安全保证。
-
std::vector的resize、reserve、push_back等操作，在 C++11 及以后，仅当std::is_nothrow_move_constructible_v<t></t>为true且std::is_nothrow_move_assignable_v<t></t>也为true时，才敢放心移动 - 如果你的类有 noexcept 移动构造，但没写 noexcept 移动赋值，
std::vector依然可能退化为拷贝 - 注意：即使你写了
T(T&&) noexcept，若其内部调用了可能抛异常的函数（比如new、非 noexcept 的成员移动），整个移动构造就不是noexcept—— 编译器会检测并让std::is_nothrow_move_constructible_v<t></t>返回false
如何正确声明移动操作并验证
别靠猜，用 static_assert 在编译期确认：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
struct MyType {
std::string data;
MyType(MyType&& other) noexcept : data(std::move(other.data)) {}
MyType& operator=(MyType&& other) noexcept {
data = std::move(other.data);
return *this;
}
};
static_assert(std::is_nothrow_move_constructible_v<MyType>, "MyType must be nothrow move constructible");
static_assert(std::is_nothrow_move_assignable_v<MyType>, "MyType must be nothrow move assignable");
关键点：
- 移动构造和移动赋值都必须显式加
noexcept，缺一不可 - 所有被移动的成员（如
std::string）本身也得是noexcept可移动的；否则你的类自动失去该属性 - 不要依赖编译器自动生成的移动操作——它们默认不带
noexcept（除非所有成员都满足条件且你没声明析构函数等） - 可以用
std::cout快速测试，但生产代码里建议用static_assert
容易被忽略的兼容性陷阱
某些标准库实现（尤其是旧版 libstdc++ 或 MinGW）对 noexcept trait 的检查不够严格，可能误判；而 MSVC 和较新 libc++ 通常更符合标准。这意味着同一段代码，在不同平台/编译器下，std::vector 可能走移动路径或拷贝路径，性能差异明显。
另一个坑是自定义分配器：即使类型满足 noexcept 移动，若分配器的 construct 或 destroy 抛异常，整体仍不安全——std::is_nothrow_move_constructible 不管分配器的事。
真正要达成强异常安全，光靠这个 trait 不够：你得控制住所有可能抛异常的环节，包括资源申请、成员移动、甚至自定义 delete 表达式。它只是拼图中最显眼的一块。
