unsafe.Sizeof返回值大于字段和是因为编译器按字段顺序插入padding以满足对齐要求，且结构体总大小需为最大字段对齐值的整数倍；用unsafe.Offsetof可定位填充位置。
为什么unsafe.Sizeof返回值比字段加总大很多
因为 Go 编译器严格按你写的字段顺序分配内存，不重排、不压缩，只在必要位置插入 padding 字节，确保每个字段起始地址满足其对齐要求。比如 int64 必须从 8 的倍数地址开始，若前一个字段是 bool（占 1 字节），编译器就在中间补 7 字节——这部分纯属浪费，但 CPU 访问必须如此。
结构体总大小还必须是其最大字段对齐值的整数倍（如含 int64，整体大小必为 8 的倍数），所以末尾也可能补空。
-
type Bad { a bool; b int64; c int32 }字段和是 1+8+4=13，但unsafe.Sizeof(Bad{})返回 24 - 原因：a 后补 7 字节让 b 对齐到 offset 8；c 占 offset 16；末尾再补 4 字节使总大小对齐到 8 的倍数（24）
- 这不是 bug，是硬件对齐规则在语言层的体现
怎么用unsafe.Offsetof定位哪段被填了
光看 unsafe.Sizeof 只知道“总大了”，但不知道“哪漏了”。真正定位填充位置，得靠 unsafe.Offsetof 算字段间间隙：
- 如果
unsafe.Offsetof(s.b) - unsafe.Offsetof(s.a) > unsafe.Sizeof(s.a)，说明 a 和 b 之间有padding - 示例：
type S { a bool; b int64 }→unsafe.Offsetof(s.a)=0，unsafe.Offsetof(s.b)=8，差值 8 > 1 → 中间填了 7 字节 - 别用
reflect.TypeOf(x).Field(i).Offset替代——它和unsafe.Offsetof等价，但语义模糊，容易误读
更直观的方式是跑个最小 main：
立即学习“go语言免费学习笔记（深入）”；
import "unsafe"<br>s := struct{ a bool; b int64 }{}<br>fmt.Println(unsafe.Offsetof(s.a), unsafe.Offsetof(s.b), unsafe.Sizeof(s)) // 输出: 0 8 16
int64 和 bool 直接连着写会触发 7 字节填充
这是最常见也最容易踩的坑：把小字段（bool、byte、int8）放在高对齐字段（int64、指针、string）前面或中间，几乎必然引发大片 padding。
-
type Bad { a bool; b int64; c bool }→a后补 7，c前又得对齐到 8 的倍数，再补 7，总大小 32 -
type Good { b int64; a bool; c bool }→b占 0–7，a和c占 8–9，末尾补 6 字节对齐到 16 → 总大小 16 - 不是“小字段不能放前面”，而是“小字段夹在大字段之间”才危险；集中放末尾反而高效
- 多个
bool连续声明，比单个bool插在两个int64中间省空间得多
嵌套结构体的对齐不能只看顶层字段顺序
内嵌结构体本身有独立对齐要求，它的首地址必须满足其内部最大字段的对齐约束。外层字段若没对齐，就会在外层字段和嵌套 struct 之间插 padding。
-
type Inner struct { x byte; y int64 }单独占 16 字节（x 后补 7，y 占 8–15） -
type Outer { a bool; inner Inner }→a占 offset 0，但inner要求起始地址 % 8 == 0，所以 a 后补 7 字节，inner从 offset 8 开始 → 总大小至少 8 + 16 = 24 - 改成
type Outer { inner Inner; a bool }→inner从 0 开始，a紧跟在 offset 16，末尾补 7 → 总大小仍是 24，但布局更可控 - 验证必须逐层用
unsafe.Offsetof：先查外层字段偏移，再查内层字段相对于外层的偏移
真正难优化的从来不是单层 struct，而是带嵌套、含 slice 或 interface{} 的组合——它们的对齐行为更隐蔽，必须实测，不能靠经验推断。
