std::is_nothrow_move_constructible 仅检查移动构造函数是否声明为 noexcept，不验证实际行为，也不能保证强异常安全；它只是构建强异常安全的前提条件之一，而非充分保障。
std::is_nothrow_move_constructible 是什么，它真能保证强异常安全吗
不能。它只告诉你 T 的移动构造函数是否被声明为 noexcept（或隐式满足），不验证实际行为，也不保证整个移动操作链（比如成员、基类的移动）都真正不抛异常。它的返回值是编译期常量，但仅基于声明签名——如果某个成员移动构造函数声明为 noexcept 却内部调用了可能抛异常的代码，std::is_nothrow_move_constructible_v<t></t> 仍可能为 true。
所以它不是“安全保障”的开关，而是你做判断的**前提条件之一**：只有它是 true，你才有可能构建强异常安全的移动逻辑；但它为 true 不代表你已经做到。
怎么正确检查并依赖这个 trait
直接用 std::is_nothrow_move_constructible_v<t></t> 是最常见写法，但要注意三点：
- 必须在完整类型上下文中使用：模板中若
T尚未完全定义（如前向声明后立即检查），结果可能是false或 SFINAE 失败 - 对数组类型要小心：
std::is_nothrow_move_constructible_v<int></int>是false，因为内置数组不提供移动语义；应检查元素类型int，而非数组本身 - 继承关系会影响结果：若基类移动构造函数不是
noexcept，即使派生类显式写了T(T&&) noexcept，只要它调用了基类的非noexcept移动构造函数，整个移动构造就不是noexcept，trait 也会返回false
示例：
struct Good {
std::string s;
Good(Good&&) noexcept = default; // string 的移动构造是 noexcept → 整体 noexcept
};
static_assert(std::is_nothrow_move_constructible_v<good>); // ✅</good>
在容器操作中它起什么实际作用
标准容器（如 std::vector）在扩容或重排时，会根据 std::is_nothrow_move_constructible_v<t></t> 和 std::is_nothrow_copy_constructible_v<t></t> 决定用移动还是拷贝来迁移元素。例如：
- 如果
T可noexcept移动，std::vector::resize或push_back扩容时优先移动——这避免了深拷贝开销，也使异常安全策略更可控 - 但如果
T不可noexcept移动，容器退回到拷贝（前提是可拷贝），否则直接static_assert失败 - 注意：
std::vector<:unique_ptr>></:unique_ptr>扩容时几乎总是移动，因为std::unique_ptr的移动构造是noexcept；而std::vector<:string></:string>在 C++11/14 中未必，取决于标准库实现对std::string移动的noexcept声明是否到位
你以为加了 noexcept 就万事大吉？这些地方容易漏掉
手动写移动构造函数时，最容易忽略的是「隐式调用的成员/基类操作」：
- 没显式标记
noexcept的成员移动构造函数，会导致整个类的移动构造自动变成可能抛异常（即使函数体为空） - 自定义析构函数存在且非
noexcept（虽然 C++11 起析构默认noexcept，但显式写成~T() throw()或~T() noexcept(false)会破坏契约） - 移动赋值运算符是否
noexcept不影响std::is_nothrow_move_constructible，但它影响容器的swap和erase异常安全——别混淆这两个 trait - 模板类中，依赖的模板参数
U是否满足该 trait，必须用static_assert或requires（C++20）显式约束，否则错误只在实例化时暴露
真正关键的不是“有没有这个 trait”，而是你是否把所有参与移动路径的类型都推到 noexcept 边界上——包括间接依赖的第三方类型。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
