std::is_assignable是编译期类型 trait，用于检查“T t; t = u;”是否合法，不执行实际赋值，常用于SFINAE或static_assert；参数顺序为对应“T = U”，对cv限定符和引用类型敏感，非运行时函数。
std::is_assignable 是编译期判断，不是运行时函数
它不执行赋值操作，只检查类型 T 是否能被 U 赋值（即 T t; t = u; 在语法和语义上是否合法）。常用于 SFINAE 或 static_assert 中拦截错误，而不是“试一下再决定”。
- 常见错误现象：
std::is_assignable<int std::string>::value</int>返回true，但实际写int& r = "hello";会编译失败——因为std::is_assignable检查的是“T对象能否接受U类型的赋值”，而int&是引用类型，其“赋值”行为等价于所引用对象的赋值，这里实际在检查int能否从std::string赋值（答案是不能），所以正确写法应是std::is_assignable<int const char></int>或更稳妥地用std::is_assignable<int std::string></int>配合完美转发语境 - 使用场景：模板参数约束，比如实现一个仅接受可赋值类型的容器
assignable_vector；或在enable_if中排除不支持赋值的类型（如std::unique_ptr的拷贝赋值被删除） - 参数顺序是
std::is_assignable<t u></t>，即 “T = U” 是否成立。别写反成<u t></u>，否则逻辑全错
注意 cv 限定符和引用类型对结果影响极大
std::is_assignable 对 const、volatile、左值/右值引用非常敏感，稍不注意就得出反直觉结果。
- 例如：
std::is_assignable<const int>::value</const>是true（绑定临时量合法），但std::is_assignable<int const int>::value</int>是false（非常量引用不能绑定 const 左值） - 又如：
std::is_assignable<:vector>&, std::vector<double>&&>::value</double></:vector>通常是true（移动赋值存在），但std::is_assignable<:vector>&, std::vector<double>&></double></:vector>可能为false（若无拷贝赋值重载或被显式删除） - 建议：泛型代码中优先用
std::declval构造表达式上下文，比如std::is_assignable<decltype>() = std::declval<u>()), void>::value</u></decltype>更贴近真实调用场景
与 std::is_copy_assignable / std::is_move_assignable 的关系
它们不是互斥替代，而是不同抽象层级：后两者是前者的特例封装。
-
std::is_copy_assignable<t></t>等价于std::is_assignable<t const t></t> -
std::is_move_assignable<t></t>等价于std::is_assignable<t t></t> - 别用
std::is_assignable<t u></t>替代std::is_copy_assignable<t></t>做类型约束——除非你明确需要跨类型赋值检查（比如std::string接收const char*） - 性能/兼容性：三者都是标准库内建特性（compiler intrinsic），无运行时开销；C++11 起可用，但部分老编译器（如 GCC 4.7 之前）对复杂模板推导支持不全，建议加
static_assert验证关键路径
容易被忽略的隐式转换干扰
std::is_assignable 默认允许用户定义的转换和标准转换，这可能导致本意是“严格类型匹配”的检查意外通过。
立即学习“C++免费学习笔记（深入）”；
- 典型坑：
std::is_assignable<:string const char>::value</:string>是true（因为std::string有const char*构造函数，且赋值运算符接受std::string，间接触发隐式构造+移动赋值） - 若要禁用隐式转换，得手动模拟“直接初始化”语义，比如结合
std::is_constructible和std::is_assignable组合判断，或改用 Concepts（C++20）中的assignable_from概念，它默认不考虑隐式转换链 - 调试技巧：把表达式塞进
decltype+std::declval再丢进static_assert，比单纯看::value更早暴露问题，例如：static_assert(std::is_assignable_v<MyType&, OtherType&&>, "MyType must be assignable from OtherType rvalue");
真正难的不是写对 std::is_assignable，而是想清楚你到底想约束哪一层语义：是语法上允许写那行赋值语句？还是语义上不发生隐式构造？或是 ABI 层面必须零开销？这些决定了你该用哪个 trait、要不要加 std::remove_reference_t、甚至要不要放弃 trait 改用 Concepts。
