std::is_layout_compatible 用于判断两个类型内存布局是否完全一致以确保跨语言/库二进制兼容；要求二者均为 standard-layout、非 union、成员数量及顺序相同、对应成员 layout-compatible、访问控制一致、基类 layout-compatible、且均不含位域。
std::is_layout_compatible 是干什么的
它用来判断两个类型在内存布局上是否完全一致，从而保证跨编译单元、跨库甚至跨语言（比如 C 和 C++）传递对象时不会因 ABI 差异出错。这不是类型等价检查，而是“它们的二进制排布能不能互换”——比如 struct A 和 struct B 成员顺序、类型、对齐都一样，std::is_layout_compatible_v<a b></a> 才为 true。
必须满足的条件才能返回 true
标准要求所有这些条件同时成立，缺一不可：
- 两个类型都必须是 standard-layout 类型（即满足
std::is_standard_layout_v<t></t>） - 都不是 union
- 非静态数据成员数量相同，且按声明顺序一一对应
- 对应成员类型 layout-compatible（递归判断），且访问控制（public/protected/private）也一致
- 如果都有基类，则基类类型必须 layout-compatible；若一个有基类另一个没有，则 false
- 位域（bit-field）不能参与比较：只要任一类型含位域，整个比较结果为
false
典型误用场景和陷阱
很多人以为加了 [[no_unique_address]] 或调整 static_assert 就能绕过 ABI 问题，其实不行。这个元函数不关心语义，只看实际生成的二进制结构。
- 即使两个 struct 字段完全一样，但其中一个用了
[[no_unique_address]]，布局可能不同 →std::is_layout_compatible_v仍为false - 不同编译器或同一编译器不同版本对空基类优化（EBO）的实现细节可能不同 → 即使本地测试为
true，也不能保证跨工具链安全 -
enum class和底层整型（如int）永远不 layout-compatible，哪怕大小和对齐一样 - 带虚函数的类自动不是 standard-layout → 直接被排除，
std::is_layout_compatible_v必为false
一个可验证的最小示例
struct A {
int x;
char y;
};
struct B {
int x;
char y;
};
static_assert(std::is_layout_compatible_v<A, B>); // ✅ 通过
struct C {
int x;
char y;
short z; // 多一个字段
};
static_assert(!std::is_layout_compatible_v<A, C>); // ✅ 失败
struct D {
int x;
char y;
int padding; // 显式填充 ≠ 隐式填充规则
};
// 不保证与 A layout-compatible —— 因为 A 的隐式填充位置/大小由 ABI 决定，D 的 padding 是显式成员
真正难的是确保两端（比如 Rust FFI 和 C++ 导出结构）使用完全相同的 ABI 约束：不仅要 layout-compatible，还要确认对齐、调用约定、名字修饰方式全部一致。这个元函数只是第一道防线，不是银弹。
立即学习“C++免费学习笔记（深入）”；
