C++里的“看不见的空隙”：internal填充对齐到底怎么算？

你有没有试过这样写代码：

struct S {
    char a;
    int b;
};
static_assert(sizeof(S) == 8); // 猜猜它通过了吗？

结果编译器默默告诉你：没错，就是8字节。但 a 只占1字节，b 占4字节，加起来才5——那剩下的3字节去哪儿了？不是开头也不是结尾，是夹在中间的。这就是 internal（内部）填充，C++内存布局里最常被忽略、却最影响性能和跨平台兼容性的细节。

很多人一提内存对齐，就只记得“结构体总大小要对齐到最大成员对齐数”，或者“每个成员按自身对齐数偏移”。这没错，但真正决定内部空隙位置和数量的，是编译器如何执行“自然对齐约束”下的逐字段布局算法——而这个过程，不依赖注释、不看变量名，只认类型和声明顺序。

举个更典型的例子：

struct Packet {
    uint8_t  flag;
    uint32_t seq;
    uint16_t len;
};

直觉上，flag（1字节）→ seq（4字节）→ len（2字节），似乎该占 1+4+2 = 7 字节。但实际 sizeof(Packet) 是 12。为什么？因为：

• flag 从 offset 0 开始，占 [0]；
• seq 要求 4 字节对齐，所以必须从 offset 4 开始（不能紧挨着 flag 放在 offset 1）→ 中间填 3 字节（internal padding #1）；
• len 要求 2 字节对齐，当前 offset 是 4+4=8，8 已经是 2 的倍数，所以直接放 [8,9]；
• 此时总占用 offset 0~9（共10字节），但结构体整体还要对齐到 max_alignof(uint32_t, uint16_t, uint8_t) == 4 → 向上补齐到 12。

关键点来了：internal 填充只发生在“下一个成员无法紧接前一个成员末尾放置”时，且仅由该成员自身的对齐要求触发。它不是编译器“好心帮忙补整齐”，而是硬件访问规则倒逼出的硬性约束——比如在 ARM 或某些 x86 模式下，未对齐的 uint32_t 读取可能触发异常或降速 3 倍以上。

那能不能手动“挤掉”这些空隙？能，但得清楚代价。#pragma pack(1) 或 alignas(1) 确实能消灭 internal padding，但别急着加：

• 网络协议解析时用 pack(1) 很常见，因为字节流是严格按序排列的；
• 但若这个结构体后续要频繁参与计算（比如做 SIMD 批处理、放进 std::vector 大量迭代），取消对齐反而会让 CPU 在每次取 int 时多花周期做拆包拼接——实测在密集循环中，pack(1) 结构体比对齐版本慢 15%~40%，取决于 CPU 架构。

更隐蔽的问题是：internal 填充会改变 offsetof 的值，进而影响所有基于偏移的手动序列化逻辑。曾有个团队把 struct Config 的字段顺序调换后，配置文件加载突然失败——查了半天，发现旧版二进制里 version 字段在 offset 4，新版因字段重排跑到了 offset 2，而反序列化代码还硬编码着 *(uint32_t*)(buf + 4)。

所以，与其对抗 internal 填充，不如学会与它共处：

✅ 声明顺序即内存顺序：把大对齐数成员（如 double, std::size_t, std::shared_ptr）放在前面，小的（char, bool, enum class : uint8_t）往后堆——这样 internal padding 更少，总尺寸更紧凑；
✅ 用 static_assert 锁死关键偏移：比如 static_assert(offsetof(Packet, seq) == 4, "seq must be at offset 4 for legacy compat");；
✅ 需要零填充时，显式声明 std::byte _padding[3]; ——比依赖编译器自动填充更可控，也向协作者明确传达“这里本该有东西”。

最后说个容易被忽略的延伸点：union 的 internal 填充行为完全不同。union 所有成员共享起始地址，所以不存在“成员间空隙”，但整个 union 的大小仍受其最大成员对齐要求支配。如果你写：

union U {
    char c;
    double d; // 对齐要求 8
};

那么 sizeof(U) == 8，且 c 和 d 都从 offset 0 开始——这里没有 internal padding，只有 external 对齐扩展。混淆这两者，是很多跨语言绑定（比如 Rust FFI 或 Python ctypes）出错的根源。

internal 填充不是 bug，是 C++ 在抽象机器和物理硬件之间签下的沉默契约。它不声不响，却决定了你的结构体能否被 memcpy 安全传递、能否被 constexpr 初始化、甚至能否通过 std::is_trivially_copyable。下次调试内存越界或序列化错位时，不妨打开编译器的 -fdump-record-layouts（GCC）或 /d1reportAllClassLayout（MSVC），亲眼看看那些藏在字段之间的空白格子——它们不是浪费的空间，而是 CPU 和你之间，心照不宣的约定。