std::is_pod 在 C++11–C++17 中可直接判断 POD 类型但已弃用，要求类型完整且同时满足平凡性和标准布局；C++20 起需组合使用 std::is_trivial 和 std::is_standard_layout。
如何用 std::is_pod 判断 POD 类型（C++11–C++17）
在 C++11 到 C++17 中，std::is_pod 是最直接的判断方式，但它已被弃用——别急着用，先看清限制。
-
std::is_pod要求类型必须是完整类型（不能是前置声明类或未定义的模板实例），否则编译失败，错误信息通常是static_assert失败或 “incomplete type” - 它对 union、含有非 trivial 构造/析构函数的类一律返回
false，哪怕内存布局完全符合 POD 要求 - 注意：即使
std::is_pod<T>::value为true，也不能保证T可以安全用于memcpy或 C 接口——还要看是否满足 triviality 和 standard layout 两个子条件
C++20 起该用什么？std::is_standard_layout 和 std::is_trivial 的组合
C++20 删除了 std::is_pod，POD 概念被拆解为两个独立要求：标准布局（std::is_standard_layout）和平凡类型（std::is_trivial）。两者都为 true 才等价于旧 POD。
- 仅
std::is_standard_layout<T>::value == true不够：比如含虚函数的类可能是标准布局，但不平凡 - 仅
std::is_trivial<T>::value == true也不够：比如含 public 继承且非空基类的类可能平凡，但不标准布局 - 典型误判场景：
struct S { int x; std::string s; };——std::is_trivial<S>::value为false（因std::string非平凡），哪怕x是 POD 成员
为什么不能只靠 sizeof 或 offsetof 推断？
有人试图用 offsetof 检查成员偏移、或用 sizeof 对比手动计算值来“验证” POD，这是危险的。
-
offsetof对非标准布局类型是未定义行为，编译器可能静默接受但运行时出错 - 即使偏移看起来“合理”，也不能说明构造/析构/拷贝是 trivial 的——例如含
const成员的类，offsetof可能正常，但std::is_trivial为false - 编译器优化（如空基类优化、成员重排）可能让手动计算的
sizeof与实际不符，尤其跨平台时
实际使用建议：优先检查 trivial + standard layout，而非“POD”这个模糊概念
现代代码里，“需要 POD” 往往真实意图是：能用 memcpy 安全复制、能与 C ABI 互操作、或能放在 std::vector<T> 中做 realloc。这些需求对应不同子集：
立即学习“C++免费学习笔记（深入）”；
- 若目标是 C 兼容结构体（如网络协议包），重点确保
std::is_standard_layout<T>::value且无引用/非静态成员函数/虚函数 - 若目标是零成本复制（如高性能数值容器），则
std::is_trivially_copyable<T>::value更准确——它覆盖了 POD，也包括std::array<int, 4>这类非 POD 但可 memcpy 的类型 - 检查时写成
static_assert(std::is_trivial_v<T> && std::is_standard_layout_v<T>, "T must be POD-like");，比依赖已删的std::is_pod更可持续
真正容易被忽略的是：POD 判断不是一次性动作。模板中使用时，T 可能随实例化变化；继承链中某个基类加了个 virtual 就会让整个派生类失效——得在关键接口处做 static_assert，而不是只在定义处看一眼。
