std::is_constant_evaluated() 仅指示当前是否在常量求值上下文中执行，不反映类型是否支持 constexpr 移动；后者要求移动构造函数为 constexpr、类型为字面类型，且所有子对象移动操作均满足 constexpr 约束。
不能用 std::is_constant_evaluated() 判断类是否可被常量求值移动 —— 它只告诉你当前是否在编译期求值，和“类是否支持 consteval 移动”完全无关。
为什么 std::is_constant_evaluated() 和“可被常量求值移动”不是一回事
std::is_constant_evaluated() 是一个运行时（但编译期也可见）的布尔提示函数，它只回答“当前这段代码是否正在被编译器作为常量表达式求值”。它不检查类型、不验证构造函数或移动操作符是否满足 constexpr / consteval 约束，更不判断对象是否实际能参与常量求值上下文中的移动。
所谓“可被常量求值移动”，本质是：该类型的移动构造函数（或移动赋值运算符）是否为 constexpr（C++20 起允许），且其所有子对象的移动也满足同样条件；同时，该对象本身必须是字面类型（literal type），且处于常量求值上下文中（如 constexpr 变量初始化、模板非类型参数等）。
常见误用场景：
立即学习“C++免费学习笔记（深入）”；
- 在普通函数里调用
std::is_constant_evaluated()，然后据此返回不同实现 —— 这无法保证移动操作本身是 constexpr 的 - 以为只要
is_constant_evaluated()返回true，就能安全调用std::move(x)并用于常量表达式 —— 错。如果T的移动构造函数不是constexpr，整条表达式直接编译失败
真正要查的是：类的移动构造函数是否为 constexpr
C++ 标准库没有提供 std::is_move_constructible_constexpr_v<t></t> 这样的类型特征。你需要手动验证或约束：
- 检查
T是否为字面类型：std::is_literal_type_v<t></t>（C++17 起已弃用，改用std::is_trivially_destructible_v<t> && std::is_trivially_copyable_v<t></t></t>+ 所有非静态成员/基类均为字面类型） - 确认
T的移动构造函数声明为constexpr（或隐式满足，例如空类、仅含constexpr成员的类） - 确保移动过程中不触发任何非
constexpr行为（如动态内存分配、虚函数调用、new、throw、I/O 等）
示例：
struct TrivialMove {
int x;
constexpr TrivialMove(TrivialMove&&) = default; // ✅ 隐式 constexpr
};
<p>struct NonConstexprMove {
std::string s;
constexpr NonConstexprMove(NonConstexprMove&&) = default; // ❌ std::string 移动非 constexpr
};</p><p>static_assert(std::is_trivially_destructible_v<TrivialMove>);
// 但无法 static_assert 其移动构造函数是 constexpr —— 编译器只在使用时诊断
怎么实测一个类能否在常量求值中被移动
最可靠的方式是**直接写一个最小常量表达式场景并尝试编译**：
- 用
constexpr变量初始化触发移动：constexpr T t2 = std::move(t1); - 用作模板非类型参数（C++20）：
template<t obj> struct X {};</t>，再实例化X<:move></:move> - 放在
consteval函数内执行移动，并返回结果
只要编译通过，就说明该类型在此上下文中可被常量求值移动。失败时错误信息通常指向具体哪个成员或操作违反了 constexpr 约束，比如：
error: call to non-constexpr function 'std::basic_string<char>::basic_string(basic_string&&)'</char>
注意：即使类满足所有条件，若移动源对象（如 t1）本身不是常量表达式（例如来自函数参数或运行时变量），std::move(t1) 仍无法进入常量求值路径 —— std::is_constant_evaluated() 在此时返回 false，但这不是类型问题，而是使用方式问题。
别把 std::is_constant_evaluated() 当类型特征用
它唯一合法用途是配合分支逻辑，在同一函数内提供 constexpr / runtime 两套实现（即所谓的“constexpr-if 替代方案”），例如：
constexpr int foo(int x) {
if (std::is_constant_evaluated()) {
return x * x; // 编译期算
} else {
return expensive_runtime_calc(x); // 运行期算
}
}
但它绝不应出现在类型约束、static_assert 或 SFINAE 中试图推导“该类是否支持 constexpr 移动”。这种用法既无效，也掩盖了真正需要检查的点：类定义本身是否合规。
最容易被忽略的一点：移动操作是否 constexpr，取决于整个调用链上每个步骤的 constexpr 属性 —— 包括所有基类、成员、自定义移动构造函数体内的每一条语句。哪怕一个 ++i 写在移动构造函数里，而 i 是 volatile，就全盘失败。
