std::is_constant_evaluated 仅在函数体内指示当前是否处于常量求值上下文，不用于判断类型是否支持constexpr移动；后者需确保移动构造函数为constexpr且所有成员/基类均满足常量求值要求。
不能直接用 std::is_constant_evaluated 判断“类是否可被编译期常量求值移动”——它压根不干这事，而且这个说法本身混淆了两个正交概念。
什么是 std::is_constant_evaluated 的真实用途
它只在函数体内返回一个 bool，告诉你「当前这段代码是否正在常量求值上下文中执行」，比如在 constexpr 函数里被编译器当成常量表达式求值时返回 true，否则（如运行时调用）返回 false。它不检查类型、不检查构造函数、更不检查移动语义是否满足常量求值要求。
常见误用场景：
- 在类定义外写
static_assert(std::is_constant_evaluated(), "...")—— 编译失败，因为该函数只能在函数体内调用 - 试图用它检测某个类是否有
constexpr移动构造函数 —— 完全无效，它不 introspect 类型 - 在模板中对
T做std::is_constant_evaluated判断 —— 语法错误，它不是类型特征
判断“类能否在编译期被移动”的实际路径
所谓“编译期可移动”，本质是：该类的移动构造函数/移动赋值运算符是否被声明为 constexpr，且其所有操作（包括成员移动、基类移动、noexcept 约束等）都满足常量求值要求。这依赖的是标准规定的 constexpr 函数约束，而非运行时或元编程探测。
实操建议：
- 显式给移动构造函数加
constexpr并确保它不调用非constexpr函数（如std::malloc、new、I/O） - 确认所有非静态数据成员和基类都支持
constexpr移动（例如不含std::string、std::vector，它们的移动构造函数不是constexpr） - 用
static_assert验证具体表达式能否常量求值，例如：struct S { constexpr S(S&&) = default; };static_assert([]{ S a; return S(std::move(a)); }() == S{}); // 若通过，说明该移动在常量求值中可行 - 注意：即使移动构造函数是
constexpr，若对象含const成员或引用成员，仍可能无法移动（与常量求值无关，而是语言规则限制）
为什么没有类似 std::is_move_constructible_v 的 constexpr 版本
C++ 标准库目前没有提供 std::is_constexpr_move_constructible_v 这类类型特征，根本原因是：是否能常量求值取决于**具体调用上下文**，而不仅是类型本身。同一个 constexpr 移动构造函数，在不同参数（比如是否指向常量内存、是否满足 lifetime 要求）下可能成功或失败。
这意味着：
- 你无法靠一个 trait 在编译期断言 “T 总是可以 constexpr 移动”
- 必须针对具体使用模式写测试表达式，用
static_assert+ lambda 或变量初始化来验证 - Clang/GCC 在
-std=c++20 -O2下会尝试把符合条件的移动内联进常量表达式，但诊断靠的是编译错误信息，比如：error: call to consteval function ... is not a constant expression
真正卡住的地方往往不是 std::is_constant_evaluated 用得对不对，而是没意识到：移动操作能否进入常量求值，取决于整个调用链的每一步是否满足 constexpr 语义——从对象创建、生命周期开始，到移动发生时的所有访问，缺一不可。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
