std::is_copy_assignable 是编译期类型特征，返回 std::true_type 或 std::false_type；正确用法是 C++17 起配合 std::is_copy_assignable_v 与 requires 约束或 std::enable_if_t，而非直接使用 ::value 做 SFINAE。
std::is_copy_assignable 是编译期判断，不是运行时函数
它本质是类型特征（type trait），返回的是 std::true_type 或 std::false_type 这种类型，不是 true/false 布尔值。直接写 if (std::is_copy_assignable<t>::value)</t> 虽然能用，但在泛型约束里几乎没人这么干——它没法阻止模板实例化失败，只是让你在运行时分支。
常见错误现象：把 std::is_copy_assignable<t>::value</t> 当作 SFINAE 条件塞进函数签名，结果编译器报错“no matching function”，而不是静默跳过——因为 ::value 是静态成员，访问它本身不触发 SFINAE。
- 正确做法是用
std::is_copy_assignable_v<t></t>（C++17 起）配合std::enable_if_t或requires子句 - 若需兼容 C++14，用
typename std::enable_if<:is_copy_assignable>::value>::type</:is_copy_assignable> - 别在
constexpr if外层用::value做模板参数推导依据，容易导致 ODR-violation 或隐式实例化失败
在 requires 约束里直接写 std::is_copy_assignable_v
C++20 的 requires 是最干净的写法，语义明确、错误信息友好，且天然支持 SFINAE-like 行为。它会在约束不满足时让整个函数模板不可选，而不是硬报错。
使用场景：实现一个只接受可拷贝赋值类型的容器插入接口，或泛型 swap 辅助函数。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template<typename T>
requires std::is_copy_assignable_v<T>
void safe_assign(T& lhs, const T& rhs) {
lhs = rhs;
}
-
std::is_copy_assignable_v<T>展开为std::is_copy_assignable<T>::value，但作为 requires 表达式的一部分，它参与约束求值而非立即实例化 - 注意：
requires不会检查T是否默认构造或可析构，只管拷贝赋值运算符是否存在且可访问 - 如果
T是 const 限定类型（如const int），std::is_copy_assignable_v<const int>为false——这是对的，因为不能给 const 对象赋值
std::is_copy_assignable 对 deleted 和 private 拷贝赋值的处理
它只关心“语法上能否写出 t = u”这件事，不关心访问权限或是否被显式删除。也就是说：private 或 = delete 的拷贝赋值运算符仍会让 std::is_copy_assignable_v<T> 返回 true，但实际调用会编译失败。
性能 / 兼容性影响：这个行为在所有标准库实现中一致（libstdc++、libc++、MSVC STL），但容易让人误判“安全”。比如你用 requires std::is_copy_assignable_v<T> 约束了一个函数，传入一个只有 private 拷贝赋值的类，约束通过，但函数体里 lhs = rhs 仍会报错。
- 真正可靠的检测要结合访问性检查，但标准库没提供现成工具；通常靠文档约定或手动
static_assert补充 - 若类定义了
operator=但标记为delete，std::is_copy_assignable_v<T>仍为true；只有当类根本没声明该运算符、且编译器也不合成时，才为false - 数组类型（如
int[3]）不满足std::is_copy_assignable_v，因为数组不可赋值；但std::array<int, 3>可以
和 std::is_trivially_copy_assignable 的关键区别
前者只要求拷贝赋值“存在且可用”，后者还要求它是平凡的（trivial）：即编译器能直接按字节复制，不调用用户定义逻辑。这对 memcpy、序列化、内存布局敏感场景很重要。
常见错误现象：用 std::is_copy_assignable_v<T> 做 zero-copy 优化前提，结果遇到非平凡类型（比如含虚函数或自定义 operator= 的类），memcpy 后对象状态损坏。
- 如果目标是“能安全 memcpy 替代赋值”，必须用
std::is_trivially_copy_assignable_v<T> -
std::is_trivially_copy_assignable_v<T>为true⇒std::is_copy_assignable_v<T>必为true，但反过来不成立 - POD 类型一般两者都为
true；带自定义operator=的类，前者为false，后者可能为true
std::is_copy_assignable_v，而是想清楚你要拦住什么：是语法错误？访问控制问题？还是对象语义完整性？这几个层次混在一起时，单靠一个 type trait 很难兜底。 
