std::is_move_assignable 是编译期类型特征，仅检查类型t是否具有可访问、非删除的移动赋值运算符，不执行任何运行时操作；传入必须是类型名而非变量，且cv限定或引用类型恒为false。
std::is_move_assignable 是编译期判断，不是运行时函数
它不执行任何移动赋值操作，只是检查类型 T 是否声明了可访问的、非删除的移动赋值运算符（T& operator=(T&&)）。常见误解是把它当运行时工具用，结果发现“明明能 move 却返回 false”——大概率是因为你传入的是左值表达式或 cv 限定类型。
- 必须传入类型名，不是变量名：
std::is_move_assignable_v<t></t>正确，std::is_move_assignable_v<decltype></decltype>要小心x的值类别和 const/volatile 修饰 - 对
const T、T&、const T&等引用/限定类型，结果恒为false，因为这些类型本身不可被移动赋值 - 如果类显式 = delete 了移动赋值，或只有拷贝赋值且未自动生成移动赋值（比如有用户定义的析构函数），也会返回
false
在模板容器中做 SFINAE 或 concepts 约束时怎么用
想让容器只接受支持移动赋值的类型？别直接 static_assert，那会硬报错。应该用约束机制让不满足的类型自然剔除重载或特化。
- 传统 SFINAE：用
std::enable_if_t<:is_move_assignable_v>, int> = 0</:is_move_assignable_v>作为函数模板参数 - C++20 后优先用 concepts：
requires std::is_move_assignable_v<t></t>更清晰，且错误信息更友好 - 注意：仅检查移动赋值还不够——高效容器通常还要求
std::is_nothrow_move_assignable_v<t></t>，否则异常安全策略会退化（比如std::vector::resize在扩容时可能需要强异常保证）
为什么 std::vector::push_back(T&&) 不总是触发移动？
即使 std::is_move_assignable_v<t></t> 为 true，push_back(std::move(x)) 也可能调用拷贝赋值——根本原因是：移动赋值是否被选中，取决于实参的类型推导结果，而不是你“想不想移”。
- 如果你传的是
T&类型的左值，哪怕加了std::move，模板推导仍可能得到T&，进而匹配到拷贝赋值（尤其当移动赋值是noexcept不成立时，编译器可能保守选择） - 确保移动发生的关键是：目标类型必须是右值引用，且移动赋值未被删除、未被隐式抑制（比如类中有自定义拷贝构造但没写移动构造）
- 验证方法：在
T的移动赋值运算符里加日志（或断点），比查std::is_move_assignable更直接
容易被忽略的兼容性陷阱：聚合类与默认移动语义
结构体或类没有用户定义的移动赋值，也不等于它支持移动赋值——C++11/14/17 对“自动生成移动赋值”的规则变化很大，老代码升级后可能突然失效。
立即学习“C++免费学习笔记（深入）”；
- C++11：只要没用户定义拷贝/移动/析构中的任意一个，就自动生成移动赋值；C++14 放宽为“只要没用户定义拷贝/析构，且所有成员都可移动”，才生成
- 含有
std::array成员的类，在 C++17 前可能因std::array内部实现不提供移动赋值而整体不可移动 - 跨标准版本移植时，别只信
std::is_move_assignable_v的结果，用static_assert锁定行为更稳妥：static_assert(std::is_move_assignable_v<mystruct>, "MyStruct must be move-assignable");</mystruct>
真正卡住性能的，往往不是“能不能 move”，而是“有没有 noexcept 移动赋值”和“编译器是否敢在关键路径上用它”。检查 std::is_nothrow_move_assignable_v 比单纯看 is_move_assignable 更接近实际容器行为。
