constexpr移动构造函数必须显式声明为constexpr，所有成员和基类均为字面类型且其移动构造函数也为constexpr，禁止运行时操作。
constexpr 移动构造函数需要满足什么条件
一个类要支持在 constexpr 上下文中被移动（比如用 std::move 构造新对象），它的移动构造函数必须是 constexpr 的，且所有被调用的成员函数、基类操作、成员初始化都必须是字面类型（literal type）并可常量求值。
常见错误是：移动构造函数声明了 constexpr，但内部调用了非 constexpr 函数（如 std::memcpy、new、非 constexpr 成员函数），或移动了含非字面类型成员（如 std::string、std::vector）的对象 —— 这会导致编译失败，报错类似：call to non-constexpr function 或 non-literal type。
- 移动构造函数必须显式标记为
constexpr（C++20 起隐式 constexpr 不再适用于移动构造） - 所有数据成员必须是字面类型（
int、std::array、自定义的constexpr类等），不能含std::string、std::unique_ptr等运行时资源管理类型 - 若类有基类，基类的移动构造函数也必须是
constexpr - 禁止在移动构造中执行任何运行时行为（如抛异常、动态内存分配、I/O）
如何检测一个类是否支持 constexpr 赋值（copy/move assignment）
不能靠“试编译赋值语句”来判断，因为即使赋值运算符是 constexpr，编译器也可能因上下文不满足而拒绝求值。可靠方式是结合 std::is_trivially_copyable_v 和 SFINAE 检测 + 实际 constexpr 上下文验证。
最实用的检查方法是写一个最小 constexpr 作用域，强制触发求值：
constexpr auto test_assign() {
MyType a{1, 2};
MyType b{3, 4};
b = std::move(a); // 若此处报错，说明 move assignment 不 constexpr
return b;
}
如果这段代码无法通过编译，就说明 MyType::operator=(MyType&&) 不满足 constexpr 要求。注意：该运算符必须显式声明为 constexpr（C++20 起不自动推导）；且函数体只能包含允许在常量表达式中出现的操作。
- 赋值运算符必须声明为
constexpr，且不能是deleted 或= default（除非所有成员都 trivial 并满足字面类型） -
= default的移动赋值在 C++20 中仅当类是“字面类型”且所有成员/基类的移动赋值均为constexpr时才隐式为constexpr - 若类含
const或引用成员，移动赋值无法生成（或无法 constexpr），因为它们不可重新绑定
为什么 std::is_literal_type 已废弃，现在该怎么查
std::is_literal_type 在 C++20 中被移除，因为它过于粗略 —— 判定为 true 并不意味着你能对它做 constexpr 移动或赋值，只说明它“可能”参与常量表达式。
真正有用的是组合判断：
-
std::is_trivially_destructible_v：析构不能有副作用 -
std::is_trivially_move_constructible_v和std::is_trivially_move_assignable_v：仅对 trivial 类型有效，但 trivial 类型天然支持 constexpr 移动（只要无非字面成员） - 更关键的是：自己写一个
constexpr函数尝试调用移动/赋值，并依赖编译器诊断 —— 这是唯一能反映真实约束的方式 - Clang/GCC 的
-fconstexpr-backtrace或-fconstexpr-depth=可帮助定位哪一步卡住
实际项目中容易忽略的坑
很多人以为只要把移动函数标上 constexpr 就万事大吉，结果在 constexpr 容器（如 std::array 初始化）里一用就崩。根本原因常藏在细节里：
- 类里有个
static inline const std::string_view sv = "hello"—— 表面看没问题，但std::string_view的构造函数在 C++20 前不是constexpr，GCC 12+ 才完全支持 - 移动赋值里写了
this->~T(); new (this) T(std::move(other));—— 即使T是字面类型，显式析构+重构造在 constexpr 上下文中是非法的（C++20 禁止在 constexpr 中调用析构函数） - 使用了
[[no_unique_address]]成员，而该成员类型本身不满足字面要求 —— 编译器仍会检查其类型约束 - 模板类特化时忘了对每个实例化都验证，比如
Vec可 constexpr 移动，但Vec<:string>绝对不行
真正可靠的验证，永远是在目标标准（C++20/C++23）下，用目标编译器，在真实常量表达式中执行一次移动或赋值 —— 其他都是推测。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
