std::is_trivially_assignable检测类型T的拷贝赋值是否可由编译器以bitwise copy（如memcpy）安全完成，要求T可赋值且赋值行为平凡（无用户定义逻辑、虚函数、非平凡成员/基类等）。
std::is_trivially_assignable 是什么，它到底在测什么
它测的不是“类型有没有定义 operator=”，而是“该类型的对象能否用底层比特拷贝（bitwise copy）安全地完成赋值”——也就是编译器能否跳过构造/析构/自定义逻辑，直接用 memcpy 级别操作完成赋值。这要求类型满足两个条件：一是可赋值（T& operator=(const T&) 合法），二是该赋值行为是“平凡的”（trivial），即不调用用户定义函数、不涉及虚函数、不触发非平凡基类或成员的赋值等。
常见误判点：std::is_trivially_assignable 为 true 并不意味着 T 一定有默认的合成赋值运算符；它只说明**如果有合法赋值表达式，那它必然是平凡的**。比如空类、POD 结构体、仅含 trivial 成员的类通常满足；但只要有一个成员的赋值是非平凡的（如 std::string、std::vector），整个类型就不是 trivially assignable。
怎么正确使用 std::is_trivially_assignable 判断 T 的赋值是否平凡
必须传入两个模板参数：目标类型（左值引用的目标）、源类型（右值/常量引用的来源）。最常用的是判断“自身赋值是否平凡”，即 std::is_trivially_assignable —— 注意第一个参数是 T&（赋值运算符返回类型），第二个是 const T&（典型参数类型）。C++17 起也支持 std::is_trivially_assignable_v 缩写形式。
- 错误写法：
std::is_trivially_assignable（少参数，编译失败） - 危险写法：
std::is_trivially_assignable（第二个参数不是引用，可能触发移动赋值路径，语义不同） - 正确写法：
std::is_trivially_assignable_v（覆盖最常见的拷贝赋值场景） - 若需同时覆盖移动赋值，可额外检查
std::is_trivially_assignable_v，但多数泛型代码只关心拷贝赋值的平凡性
实际中容易踩的坑：继承、模板、const 成员的影响
平凡赋值要求整个赋值链路中所有参与的基类和成员都满足 trivial 条件。哪怕一个 const 成员，也会让合成赋值运算符变为 deleted，进而导致 std::is_trivially_assignable 返回 false（因为类型根本不可赋值）。
示例：
struct A { int x; };
struct B { const int y; }; // 含 const 成员 → 无合成 operator=
struct C : A { B b; }; // 继承 + 非平凡成员 → is_trivially_assignable_v<c const c> == false</c>
- 继承虚基类或含虚函数的基类 → 赋值必然非平凡
- 模板类如
std::array：平凡性取决于T；std::array是平凡的，std::array<:string>不是 - 显式删除或默认化赋值运算符：
= default可能生成平凡版本（前提是成员/基类都平凡）；= delete或用户定义则直接导致不可赋值
为什么不能只靠 sizeof 或 memcpy 推断？
有些类型看似“纯数据”，比如手动管理内存的结构体，但只要它重载了 operator=（哪怕内部只是 memcpy），就不算 trivial —— 因为标准要求“平凡”必须由编译器自动合成，而非用户手动模拟。反过来，某些类型没有显式定义 operator=，但因含非平凡成员（如 std::mutex），编译器会隐式删除合成版本，此时 std::is_trivially_assignable 也会是 false（因为连基本可赋值都不满足）。
真正关键的边界在于：你是否打算在 std::memcpy、std::memmove、placement new 等底层操作中绕过赋值运算符。如果是，那必须确保 std::is_trivially_assignable_v 为 true，且 std::is_trivially_destructible_v 和 std::is_trivially_copyable_v 同时成立 —— 少一个，memcpy 后的对象状态就不可靠。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
