std::is_standard_layout 不能单独保证 memcpy 安全，必须同时满足 trivially copyable、abi 固定、无指针引用；常见 false 原因包括虚函数、多非空基类、访问控制不一致；应配合 static_assert 编译期检查。
std::is_standard_layout 能不能保证 memcpy 安全
不能直接保证。它只说明类满足标准布局要求（如无虚函数、所有非静态成员同访问控制、单继承链等），但不保证没有 padding 或跨平台一致——比如 std::is_standard_layout_v<t></t> 为 true 的类，在 x86_64 和 ARM64 上 sizeof(T) 可能相同，但字段对齐边界不同，导致 memcpy 后读取越界或值错乱。
真正安全的 memcpy 场景需要同时满足：
-
std::is_standard_layout_v<t></t>为true -
std::is_trivially_copyable_v<t></t>为true（缺一不可） - 目标平台 ABI 明确且固定（例如只跑 Linux x86_64 + GCC 12+）
- 类中不含指针或引用（否则 memcpy 后悬空）
哪些类会被 std::is_standard_layout 判定为 false
常见误判点不是“太复杂”，而是“不经意破坏了布局规则”。比如：
- 类里定义了任何虚函数 →
has_virtual_function破坏标准布局 - 多个基类，哪怕都空，也违反“最多一个非空基类”规则
- 成员变量混用
public/private/protected（哪怕只是加了个mutableint） - 继承链中出现非标准布局基类（哪怕子类本身很干净）
示例：struct A { int x; }; struct B : A { private: int y; }; → B 不是标准布局，因为 A 是 public，而 y 是 private，访问控制不一致。
检查时必须配合 static_assert 而非运行时 if
类型属性在编译期确定，运行时判断毫无意义。写 if (!std::is_standard_layout_v<t>) { /* error */ }</t> 不会报错，但逻辑永远走不到分支里——编译器早就把整个分支优化掉了。
正确做法是用 static_assert 在编译时报错：
struct Packet {
uint32_t len;
uint8_t data[256];
};
static_assert(std::is_standard_layout_v<packet>, "Packet must be standard layout for network serialization");
static_assert(std::is_trivially_copyable_v<packet>, "Packet must be trivially copyable");</packet></packet>
漏掉第二个 static_assert 是高频失误：标准布局但非平凡可复制（比如含 std::string 成员）的类，memcpy 会导致资源重复释放。
和 C 兼容结构体互操作的真实限制
即使 std::is_standard_layout_v<t></t> 为 true，也不能默认和 C 头文件里的 struct 一一对应。关键差异在：
- C++ 编译器可能给空基类添加 EBO（空基类优化），C 编译器不会
-
#pragma pack或alignas在 C/C++ 中行为未必一致 - 位域（bit-field）顺序和打包方式在 C 和 C++ 标准中均未完全规定
最稳妥的方式是显式用 extern "C" 声明结构体，并在 C 和 C++ 两端使用完全相同的头文件（带 #ifdef __cplusplus 保护），而不是靠 std::is_standard_layout 猜测兼容性。
这个 trait 是个必要不充分条件，真正在意内存布局时，别信它单独的返回值，得看生成的 offsetof 和 sizeof 实际值，再比对目标 ABI 文档。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
