std::is_constant_evaluated() 与“可被常量求值移动”无关，它仅反映当前上下文是否在编译期求值，不检查类型、构造函数或移动操作符；判断类是否支持常量求值移动需验证其移动构造函数是否constexpr且所有子操作均满足常量表达式约束。
不能用 std::is_constant_evaluated() 判断类是否可被常量求值移动 —— 它和移动语义无关，只反映当前上下文是否在编译期求值。
为什么 std::is_constant_evaluated() 和“可被常量求值移动”完全不是一回事
std::is_constant_evaluated() 是一个运行时返回 bool 的内联函数（C++20 引入），它在编译期常量求值路径中返回 true，在运行时路径中返回 false。它不检查类型、不检查构造函数、不检查移动操作符，更不判断“能否在 consteval 函数里调用移动构造函数”。
所谓“可被常量求值移动”，实际要问的是：一个类的移动构造函数/移动赋值运算符能否在编译期被调用？ 这取决于：是否是 constexpr（或 consteval）、是否访问了禁止在常量求值中出现的操作（如动态内存分配、虚函数调用、this-> 指针比较等）。
-
std::is_constant_evaluated()本身不能用于类型特征（type trait），无法static_assert或 SFINAE - 它只能在函数体内用，且结果依赖调用点上下文 —— 即使类有
constexpr移动构造函数，你也不能靠它“检测出这个类支持常量求值移动” - 误把它当
std::is_move_constructible_v<t></t>或std::is_trivially_move_constructible_v<t></t>的编译期等价物，会直接导致逻辑错误
真正能判断“类是否支持常量求值移动”的方法
目前 C++ 标准没有提供直接的 type trait（如 std::is_constexpr_move_constructible_v），但可通过组合约束 + 编译期测试间接验证：
- 该类必须满足
std::is_move_constructible_v<t></t>（否则连移动都不合法） - 其移动构造函数必须是
constexpr（显式声明，或由编译器隐式生成为constexpr）；注意：隐式生成的移动构造函数仅在所有非静态成员和基类都满足 trivial + constexpr 构造时才可能是constexpr - 必须能在
consteval函数中安全调用；例如：consteval T make_moved() { T a{}; return std::move(a); }若编译失败，说明移动构造函数不可用于常量求值 - 典型反例：
std::vector<int></int>的移动构造函数虽是constexpr（C++23 起），但它内部调用operator new，因此仍 不能 在常量求值中使用 —— 编译器会报错：call to allocation function 'operator new' is not allowed in a constant expression
常见踩坑：把 trivial、noexcept、constexpr 混为一谈
这三个属性相互独立，缺一不可又不能互相推出：
-
std::is_trivially_move_constructible_v<t></t>→ 表示移动是逐字节拷贝，但不保证能出现在常量表达式中（如含volatile成员就可能不行） -
noexcept是运行时异常规范，对常量求值无直接影响；但若移动构造函数抛异常，则必然不能constexpr（因为constexpr函数不允许抛异常） -
constexpr移动构造函数 ≠ 可在常量求值中调用：还需确保所有被调用的子对象操作（如成员的移动构造、基类移动构造）也都满足常量求值约束 - 自定义移动构造函数必须显式加
constexpr（C++20 起允许），否则即使函数体为空也不被视为constexpr
最可靠的方式，不是查 trait，而是写一个最小 consteval 测试函数并尝试实例化 —— 编译器报错信息比任何元编程技巧都准确。复杂类（尤其含 std::unique_ptr、容器、自定义分配器）几乎不可能在常量求值中完成移动，别试图绕过诊断直接假设“它应该可以”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
