std::is_scoped_enum_v是C++23引入的唯一标准、可靠、语义准确的编译期判断方式，仅对enum class/struct返回true，对传统enum均返回false，C++20及更早版本不支持。
std::is_scoped_enum 在 C++23 之前根本不可用
别急着查文档——std::is_scoped_enum 是 C++23 才正式加入标准的类型特征，如果你用的是 GCC 12/Clang 14 之前的版本，或者 MSVC 19.30 之前的工具链，它压根不存在。即使启用了 -std=c++20，这个 trait 也不会出现。很多项目还在 C++17/C++20 环境下维护，这时候硬写 std::is_scoped_enum_v<t></t> 会直接编译失败。
实操建议：
- 先确认编译器和标准支持：用
__cplusplus宏 + 编译器内置宏（如__GNUC__、_MSC_VER）做预检 - 若不支持，必须退回到手动判断逻辑（见下一条）
- C++23 用户也别默认开启：某些 STL 实现（如 libstdc++ 13.2）仍需显式包含
<type_traits>且依赖完整标准库配置
如何在 C++17/C++20 中可靠识别 scoped enum
核心思路是利用 scoped enum 无法隐式转换为整型、而 unscoped enum 可以这一行为差异，配合 SFINAE 或 decltype + void_t 构造探测表达式。不能只靠 std::is_enum_v，因为两者都返回 true。
一个轻量级可移植实现：
立即学习“C++免费学习笔记（深入）”；
template <typename T>
constexpr bool is_scoped_enum_v = std::is_enum_v<T> &&
!std::is_convertible_v<T, std::underlying_type_t<T>>;
注意这个判断在绝大多数场景下成立，但有例外：
- 如果 unscoped enum 显式禁用了转换（比如用
delete重载了 operator int），该检测会误判为 scoped —— 这种情况极少见，且属于非标准用法 - 枚举底层类型为
void？不可能，std::underlying_type_t<T>对合法 enum 总是定义良好 - 对
enum class E : bool {}这类底层类型窄于int的，is_convertible_v<E, bool>仍为true，所以判断依然有效
std::is_scoped_enum_v 的实际行为与陷阱
即便在 C++23 环境下，std::is_scoped_enum_v 也不是万能的“作用域开关”检测器。它只回答一个问题：这个类型是否是 enum class 或 enum struct 定义的枚举，不关心其是否有命名空间包装、是否嵌套、是否 forward-declared。
常见误用点：
-
enum class E { a }; namespace N { enum class F { b }; }→std::is_scoped_enum_v<E>和std::is_scoped_enum_v<N::F>都为true，和是否在命名空间里无关 -
enum class E : char;和enum class E;行为一致，底层类型不影响结果 -
enum class E { a }; E e = E::a; decltype(e)::a不合法 ——decltype(e)是类型，不能用::访问枚举值，这点和 unscoped enum 的 ADL 行为完全不同，但std::is_scoped_enum_v不反映这种语义差异
为什么不能仅靠名字或宏来区分
有人试图用字符串匹配（比如检查类型名是否含 "class"）或自定义宏标记（MY_ENUM(E, class)），这类做法在模板元编程中完全失效。编译器在实例化时看不到宏展开后的原始语法树，typeid(T).name() 是实现定义、不可靠，且无法在 constexpr 上下文中使用。
真正可靠的区分必须基于语言规则本身：
- scoped enum 的每个 enumerator 必须通过作用域解析符访问（
E::a），unscoped 则可直接用（a） - scoped enum 不参与整型提升，unscoped 会（影响函数重载、模板推导）
- 只有 scoped enum 支持前向声明后定义（
enum class E; ... enum class E : int { a };），unscoped 不允许
这些差异才是 std::is_scoped_enum_v 或其模拟实现所锚定的语言事实，而不是表面语法糖。
