unsafe.Sizeof返回值总大于手算和是因为编译器按对齐规则插入padding：int64/string/指针等对齐值为8，必须从8字节倍数地址开始；int32为4；bool/int8为1；结构体总大小必为最大字段对齐值的倍数；字段顺序应按对齐值降序排列而非类型大小，否则引发填充浪费。
为什么 unsafe.Sizeof 返回的值总比你手算的大
因为 Go 编译器会在字段之间插入 padding（填充字节），确保每个字段起始地址满足其对齐要求。这不是 bug，是 CPU 访问效率必需的机制。
-
int64、string、指针、interface{}的对齐值是 8，意味着它们必须从地址 % 8 == 0 的位置开始 -
int32、float32对齐值是 4 -
bool、int8、[1024]byte对齐值是 1，可紧挨着放 - 结构体总大小必须是其最大字段对齐值的倍数（比如含
int64就得是 8 的倍数）
手算字段字节数之和没用——真正决定内存布局的是 unsafe.Offsetof 和 unsafe.Alignof，不是类型大小。
怎么排字段顺序才能让 struct 更小
字段声明顺序 = 内存分配顺序，编译器不会重排。优化核心是：按对齐值降序排列，而不是按类型大小。
- 把对齐值为 8 的字段（如
int64、string、map[string]int）放在最前面 - 对齐值为 4 的字段（如
int32、float32）集中放中间 - 对齐值为 1 的字段（如
bool、int8）挤在最后，且尽量连续（避免bool–int64–bool这种“夹心”） - 嵌套 struct 按它自身的
unsafe.Alignof参与排序，不是看它里面有什么
例如：struct{a int8; b int64} 占 24 字节，而 struct{b int64; a int8} 只占 16 字节——差别全在有没有“开头税”。
立即学习“go语言免费学习笔记（深入）”；
unsafe.Offsetof 和 unsafe.Sizeof 必须一起用
光看 unsafe.Sizeof 只知道总大小，看不出 padding 分布；光看 unsafe.Offsetof 不知道字段之间是否留空。两者结合才能定位浪费点。
- 用
unsafe.Offsetof(s.field)查字段真实偏移，别靠累加类型大小推算 - 用
unsafe.Alignof(T(0))查字段对齐值，不是查unsafe.Sizeof - 数组场景下 padding 差异会被放大：每个元素都多 7 字节，1000 个就是 7KB 浪费
常见错误：以为 struct{a int8; b int64; c int32} 中 c 偏移是 9，实际是 16——因为 b 结束于偏移 15，下一个能被 4 整除的位置是 16。
cgo 场景下对齐策略必须显式同步
Go struct 和 C struct 的对齐规则可能不一致，尤其在跨语言调用时。cgo 不会自动适配，必须手动保证对齐一致，否则读写越界或数据错乱。
- C 中
struct的对齐受_Alignas或编译器默认规则影响，可能和 Go 不同 - 用
//export导出或C.struct_xxx转换前，务必验证双方sizeof和字段偏移是否一致 - 必要时用
#[repr(C)]（Rust）或__attribute__((packed))（C）强制对齐，但要清楚代价（性能下降、未对齐访问风险）
最容易被忽略的是：即使单个 struct 大小一样，数组或切片场景下 padding 差异会指数级放大——这点在高频分配或大容量缓存中尤为致命。
