std::is_trivially_copyable 是什么，能信吗？
它不是运行时检测工具，而是编译期类型特征（type trait），返回 std::true_type 或 std::false_type —— 也就是说，它只告诉你“这个类型按位拷贝是否安全”，不保证你实际调用 memcpy 就一定没问题，但它是必要前提。
常见误判点：用户常以为“没写构造函数/析构函数”就自动 trivially copyable，其实只要类里有 std::string、std::vector、虚函数表指针、或任何非 trivial 的成员（哪怕 private），整个类型就不是 std::is_trivially_copyable_v<t></t>。
怎么正确使用 std::is_trivially_copyable_v
必须搭配 constexpr if 或 SFINAE 做编译期分支；直接用 if (std::is_trivially_copyable_v<t>)</t> 没用 —— 运行时判断毫无意义，且编译器不会帮你优化掉不安全路径。
- 推荐写法：
if constexpr (std::is_trivially_copyable_v<t>) { /* memcpy 分支 */ }</t> - 模板约束写法（C++20）：
template<typename t> requires std::is_trivially_copyable_v<t> void fast_copy(T* dst, const T* src);</t></typename> - 别用
std::is_trivially_copyable<t>::value</t>—— C++17 起应统一用std::is_trivially_copyable_v<t></t>，更简洁也更不容易拼错
哪些类型会意外返回 false
看似“纯数据”的结构体，可能因隐式生成的特殊成员而失败。典型陷阱：
立即学习“C++免费学习笔记（深入）”；
- 含
std::array<:string></:string>的 struct：即使自己没写任何函数，std::string自身不是 trivially copyable，整个 struct 就不是 - 带
[[no_unique_address]]空基类的类型：若该空基类有非 trivial 析构函数，仍会导致整体不满足 - 继承自 virtual base class 的类型：哪怕虚基类本身 trivial，派生类也不再 trivially copyable
- 有
mutable std::atomic<int></int>成员：原子类型通常 non-trivial，拖累整个类型
和 memcpy 配合用时的关键限制
std::is_trivially_copyable_v<t></t> 为 true 只是 memcpy 的必要条件，不是充分条件。你还得确保：
- 对象处于生命周期内（不能对未构造或已析构的对象 memcpy）
- 目标内存已分配且对齐正确（
alignof(T)必须满足） - 源和目标地址不重叠（否则要用
memmove，但 trivially copyable 类型不保证 memmove 安全） - POD 类型 ≠ trivially copyable：C++20 废除了 POD，但老代码里容易混淆 ——
std::is_pod_v<t></t>已弃用，别再依赖它
真正要 memcpy，建议封装成模板函数并 static_assert：static_assert(std::is_trivially_copyable_v<t>, "T must be trivially copyable for raw copy");</t>
