std::is_nothrow_convertible 是 C++20 编译期类型特性，用于判断 T→U 隐式转换是否保证不抛异常，返回 std::true_type 或 std::false_type；它不运行时捕获异常，仅用于 SFINAE、requires 或 static_assert 等编译期约束。
std::is_nothrow_convertible 是 C++20 引入的类型特性，不是运行时检查工具
它不能“检查转换异常”，而是编译期判断从一个类型到另一个类型的隐式转换是否 保证不抛异常（即是否为 nothrow 转换）。你无法用它捕获或观察实际发生的异常，它只在模板实例化时给出 std::true_type 或 std::false_type。
常见误用是把它当 try/catch 替代品——这完全无效。它的作用域仅限于 SFINAE、requires 约束或 static_assert 等编译期场景。
正确使用 std::is_nothrow_convertible 的典型场景
它最常用于约束模板函数，避免因隐式转换触发异常而破坏 noexcept 规约。例如：
template <typename T, typename U>
requires std::is_nothrow_convertible_v<T, U>
U safe_convert(T&& t) noexcept {
return static_cast<U>(std::forward<T>(t));
}
要点说明：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
std::is_nothrow_convertible_v<T, U>检查的是 T → U 的隐式转换路径（含用户定义转换函数、构造函数），且要求该路径中所有参与的构造/转换操作都标记为noexcept - 若
T有operator U() noexcept，或U有U(const T&) noexcept构造函数，才可能为true - 即使转换逻辑本身不抛异常，但只要任一环节未显式声明
noexcept（如U(const T&)没加noexcept），结果就是false - 对内置类型（如
int → double）恒为true；对std::string → const char*（隐式调用c_str()）也恒为true，因为c_str()是noexcept
容易踩的坑：它不检查 explicit 构造函数和显式转换
std::is_nothrow_convertible 只关心 隐式转换。以下情况它一律返回 false，哪怕实际转换根本不抛异常：
-
U的构造函数是explicit的（哪怕带noexcept）→ 不算隐式转换路径 - 你写的是
static_cast<U>(t)或U{t}→ 这是显式转换，不在其检测范围内 - 转换依赖 ADL 函数（如非成员
operator U）但未声明为noexcept→ 即使函数体空，也判为false - 涉及多步隐式转换（如
T → V → U）→ 只要其中任意一步不可 nothrow，整体为false
替代方案：想真正捕获转换异常，得靠 try/catch
如果你的真实需求是“在运行时安全地尝试转换，并处理可能的异常”，std::is_nothrow_convertible 完全不适用。必须手动封装：
template <typename T, typename U>
std::optional<U> try_convert(const T& t) {
try {
return static_cast<U>(t); // 或调用具体转换函数
} catch (const std::exception&) {
return std::nullopt;
}
}
注意：static_cast 本身不会抛 C++ 标准异常（除非转换涉及用户代码），真正可能抛异常的是自定义转换函数或构造函数。所以关键还是看被调用的那些函数有没有 noexcept 声明。
真正容易被忽略的一点：这个类型特性只在 C++20 及以后可用，且 GCC 10+/Clang 11+ 才完整支持；MSVC 从 19.28 开始支持，但早期版本对复杂转换路径的判定有偏差。别在没确认编译器版本和标准模式（-std=c++20）的情况下默认它可靠。
