应使用 std::is_trivially_copyable<T>::value 判断类型能否安全 memcpy，它确保 memcpy 行为定义良好；std::is_pod 已弃用，仅检查 sizeof/alignof 不足，且需注意继承、union、自定义赋值等导致失效的陷阱。
如何用 std::is_trivially_copyable 判断类型能否直接 memcpy
能直接 memcpy 的类型，不等于“能随便复制”的类型。C++ 标准里真正对应“可通过内存拷贝安全传递”的概念是 std::is_trivially_copyable —— 它才是你该查的 trait，而不是 std::is_pod（已过时）或 std::is_trivial（范围太宽）。
-
std::is_trivially_copyable<T>::value为true，意味着对T对象调用memcpy是定义良好的行为（前提是目标内存已正确分配且对齐） - 常见反例：
std::string、std::vector、含虚函数的类、含引用成员或非 trivial 析构函数的类，全都不满足该 trait - 注意：即使
std::is_trivially_copyable为true，也不代表sizeof(T)就是其“有效序列化长度”——比如有填充字节（padding），memcpy会拷贝整块内存，但语义上可能只关心部分字段
为什么不能只看 std::is_pod 或手动检查 sizeof 和 alignof
std::is_pod 在 C++20 中已被弃用，它要求更严格（必须同时是 trivial 和 standard-layout），而很多现代合法类型（如带默认构造函数的结构体）虽不是 POD，却是 trivially_copyable 的。
- 仅靠
sizeof(T)和alignof(T)无法判断是否可 memcpy：它们只反映布局信息，不保证析构/构造逻辑无副作用 - 手动 memcmp 两个对象相等，不代表 memcpy 后对象状态合法 —— 比如某些类型依赖指针值或内部标记位，bitwise copy 可能破坏不变量
- 编译器不会阻止你对非 trivially-copyable 类型调用
memcpy，但结果是未定义行为（UB），运行时崩溃或静默损坏都可能发生
实际使用中怎么写安全的泛型拷贝逻辑
如果你在写序列化、内存池或跨线程传递的泛型代码，应先静态断言类型可 trivially copyable，而非运行时分支处理。
- 推荐写法：
static_assert(std::is_trivially_copyable_v<T>, "T must be trivially copyable for raw memory operations");
- 若需运行时判断（极少见），用
if constexpr分离路径：if constexpr (std::is_trivially_copyable_v<T>) { memcpy(dst, src, sizeof(T)); } else { T{src}.swap(*dst); /* or throw */ } - 不要用
std::memcpy替代赋值运算符——即使类型满足 trait，也优先走=；只有在明确需要 bypass 构造/析构（如内存池重用、零初始化后 bulk 初始化）时才用memcpy
容易被忽略的陷阱：继承、union 和 std::byte
看似简单的类型，组合后可能意外失去 trivially copyable 性质。
立即学习“C++免费学习笔记（深入）”；
- 派生类只要基类或自身含 non-trivial 成员（如
std::string成员），整个类型就不是trivially_copyable - union 若含 non-trivially-copyable 成员（哪怕未激活），整个 union 就不是
trivially_copyable（C++17 起） -
std::byte本身是 trivially copyable，但std::span<std::byte>不是——因为std::span含非 trivial 析构函数 - 自定义
operator=即使是 defaulted，也会让类变成 non-trivial，从而影响trivially_copyable判定（除非显式声明为= default且所有成员都 trivial）
标准没留模糊地带：可否 memcpy，只看 std::is_trivially_copyable；其他任何经验判断，都可能在某个编译器或优化级别下翻车。
