std::is_nothrow_constructible 是编译期 trait，仅检查构造函数声明是否为 noexcept，不验证实际行为；它与 noexcept(t{}) 语义不同，不可互换，且不等价于 is_nothrow_move_constructible。
std::is_nothrow_constructible 是编译期判断，不是运行时检测
它只看类型 T 的构造函数声明里有没有 noexcept（或隐式 noexcept(true)），不关心实际调用会不会抛异常。比如 std::vector<int></int> 的默认构造函数是 noexcept，但如果你传入一个自定义分配器，而它的构造函数没标 noexcept，那 std::is_nothrow_constructible_v<:vector>, MyAlloc></:vector> 就是 false —— 即使你根本没在代码里触发分配失败。
常见错误现象：static_assert(std::is_nothrow_constructible_v<myclass>);</myclass> 通过了，但实际构造时仍可能抛 std::bad_alloc（比如内部 new 失败）。这是因为 new 表达式本身不被 noexcept 修饰影响，除非你显式用了 new (std::nothrow)。
- 它只检查“签名是否承诺不抛”，不检查实现逻辑
- 对类模板实例化，要传全特化参数，比如
std::is_nothrow_constructible_v<:string const char></:string>，漏掉const char*就默认匹配默认构造，结果可能完全不同 - 聚合类型（如
struct S { int x; };）的默认构造是隐式noexcept，但若成员有非noexcept构造函数，则整体不是
怎么写准：注意构造函数重载和参数完美转发
模板参数顺序必须严格对应目标构造函数的参数类型。例如 std::pair<int std::string></int> 有多个构造函数：pair()、pair(const T1&, const T2&)、pair(T1&&, T2&&)……你要检测移动构造是否无异常，就得写 std::is_nothrow_constructible_v<:pair std::string>, int&&, std::string&&></:pair>，而不是只写 int, std::string。
使用场景：想在 std::vector::reserve 后做无异常扩容，得先确认元素类型的移动构造是 noexcept，否则 vector 可能退回到拷贝路径（影响性能）。
立即学习“C++免费学习笔记（深入）”；
- 引用类型要显式写出
&或&&，int和int&&是不同重载 - 对于可变参数模板（如
std::tuple），必须展开所有参数类型，不能用auto占位 - 如果类型有
explicit构造函数，且你传的是隐式转换类型（如int → double），is_nothrow_constructible仍会返回true，只要那个explicit构造函数本身是noexcept
和 noexcept(operator) 混用时容易误判
noexcept(T{}) 看的是实际表达式是否可能抛异常，而 std::is_nothrow_constructible_v<t></t> 看的是声明。两者在绝大多数标准类型上一致，但自定义类型中可能割裂：比如你写了 T() noexcept { throw 42; }，编译器允许（但违反契约），此时 std::is_nothrow_constructible_v<t></t> 是 true，而 noexcept(T{}) 是 false。
性能影响：前者是纯编译期常量，零开销；后者在某些编译器下可能触发更激进的优化（如省略栈展开信息），但语义更严格。
- 别用
noexcept(T{})替代std::is_nothrow_constructible做 trait 判断，因为无法用于 SFINAE 或requires子句 - 在
concept中应优先用std::is_nothrow_constructible_v，它支持约束推导；noexcept(...)只能用于布尔上下文 - Clang 和 GCC 对
noexcept(T{})的诊断更敏感，可能在构造函数体里有throw时直接报错，而is_nothrow_constructible不管实现
std::is_nothrow_move_constructible 和它不是一回事
这是最常被忽略的点：很多人以为“能无异常构造”就等于“能无异常移动”，但两者完全独立。比如 std::unique_ptr 的默认构造是 noexcept，但它的移动构造也是 noexcept；而某个自定义容器如果移动构造函数调用了可能抛异常的清理逻辑，那它就不是 noexcept，哪怕默认构造是。
兼容性影响：C++11 起，标准容器（如 std::vector）在扩容时，若元素类型满足 std::is_nothrow_move_constructible，才启用移动而非拷贝；仅满足 is_nothrow_constructible 不够。
- 检测移动构造必须用
std::is_nothrow_move_constructible_v<t></t>，参数就是T&& - 不要假设
is_nothrow_default_constructible成立就意味着其他构造也成立 - 类的析构函数是否
noexcept（默认是）会影响移动操作的异常安全性，但它不参与is_nothrow_constructible的判断
