Go中计算struct字段间padding需用unsafe.Offsetof和unsafe.Sizeof：先获取各字段偏移，再用后字段偏移减去前字段（偏移+大小）即得其前padding；reflect不提供padding信息。
Go 里怎么算 struct 字段间的 padding 大小
Go 没有直接暴露 padding 的 API，unsafe.Offsetof 和 unsafe.Sizeof 是唯一可靠入口。别想用反射（reflect.StructField）拿到 padding——它压根不描述内存空隙，只返回字段声明顺序和类型信息。
核心思路是：逐个字段调用 unsafe.Offsetof，再减去前一个字段的结束位置（即偏移 + 类型大小），差值就是该字段前面的 padding。
-
unsafe.Offsetof(s.f1)给出字段f1相对于结构体起始地址的偏移 -
unsafe.Sizeof(f1_value)给出该字段类型的对齐后大小（注意：不是reflect.TypeOf(f1).Size()，后者等价但略绕） - 第一个字段偏移总是 0；第二个字段偏移减去第一个字段的
Offsetof + Sizeof，就是它们之间的 padding
为什么不能用 reflect.TypeOf(s).Field(i).Offset
reflect.StructField.Offset 看起来像 padding 信息，但它其实是字段自身的内存偏移（等同于 unsafe.Offsetof），不是“上一字段末尾到本字段开头”的间隙值。它不告诉你前一个字段占了多少字节，更不会暴露编译器插入的填充字节。
常见误判场景：嵌套 struct 或含数组字段时，Offset 值跳变很大，有人以为那是 padding，其实只是内层 struct 自身对齐导致的“大步跳”，中间可能混着多个小 padding 块，无法拆分。
- 例如
struct{ a byte; b [3]uint16 }中，b的Offset是 2，但这是因[3]uint16要求 2 字节对齐，a后自动补了 1 字节 padding —— 这 1 字节你得自己算出来，reflect不给 -
reflect.StructField没有 “padding before” 或 “gap after” 字段，别找
实际计算 padding 的三步法（带示例）
以这个 struct 为例：
type S struct {
A byte
B uint32
C bool
}目标是知道 A 后、B 后各有多少 padding。步骤如下：
- 取字段地址偏移：
unsafe.Offsetof(s.A)= 0，unsafe.Offsetof(s.B)= 4，unsafe.Offsetof(s.C)= 8 - 查字段大小：
unsafe.Sizeof(s.A)= 1，unsafe.Sizeof(s.B)= 4，unsafe.Sizeof(s.C)= 1 - 算 padding：
–A后 padding =Offsetof(B) - (Offsetof(A) + Sizeof(A))= 4 − (0 + 1) = 3
–B后 padding =Offsetof(C) - (Offsetof(B) + Sizeof(B))= 8 − (4 + 4) = 0
注意：最后一个字段之后是否还有 padding（影响 unsafe.Sizeof(S{})），需单独用 Sizeof 减去最后一个字段结束位置来判断。
跨平台和编译器差异带来的坑
padding 不是 Go 语言规范的一部分，而是由底层 ABI（如 System V AMD64）和编译器（gc vs gccgo）共同决定。同一段代码在 darwin/arm64 和 linux/amd64 上 padding 可能不同。
- 结构体末尾的 padding（用于保证数组元素对齐）在
unsafe.Sizeof中已计入，但不会出现在字段间计算中 - 使用
//go:pack或struct{ _ [0]byte }强制紧凑布局会彻底改变 padding，此时上述算法依然有效，但结果和默认情况完全不同 - CGO 场景下，如果 struct 要传给 C，必须用
unsafe.Offsetof实测，别依赖文档或经验——C 头文件里的#pragma pack会影响最终布局
真正难的从来不是怎么算，而是意识到：padding 是编译期决策，运行时不可逆，且没有标准描述方式。每次换目标平台、升级 Go 版本、或加了新字段，都得重算一遍。
