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