结构体大小不是字段大小之和，因为go编译器严格按声明顺序插入padding以满足各字段对齐要求，且总大小必须为最大字段对齐值的整数倍；需用unsafe.sizeof和unsafe.offsetof实测定位填充位置。
结构体大小为什么不是字段大小之和
Go结构体实际占用内存 ≠ 所有字段unsafe.Sizeof相加。编译器会按字段声明顺序插入填充字节（padding），只为满足每个字段的对齐要求。比如struct{a uint8; b int64; c uint8}，理论9字节，实测24字节——中间7字节是编译器强制补的padding，让b能从8字节边界开始。
- 字段顺序即内存布局顺序，Go不重排、不优化、不提示
- padding只在字段之间或末尾出现，不会出现在字段内部
- 结构体总大小必须是其最大字段对齐值的整数倍（如含
int64，整体必为8的倍数）
怎么快速判断一个结构体有没有浪费空间
别靠猜，用unsafe.Offsetof和unsafe.Sizeof实测。前者告诉你每个字段真实起始偏移，后者给出最终体积；两者一比，就能定位padding在哪、占多少。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
unsafe.Offsetof(s.b)若返回16，而s.a只占1字节且s.b类型是int64，说明前面至少有7字节padding - 字段间偏移差 ≠ 字段自身大小 → 差值就是padding
- 嵌套结构体也要单独测：
unsafe.Sizeof(outer{})可能比字段大小之和多出内层尾部padding
字段排序的实用原则：不是“大到小”，而是“对齐值降序”
关键不是类型大小，而是unsafe.Alignof返回的对齐值。比如[1024]byte占1024字节，但对齐值仍是1；而string只占16字节，对齐值却是8。
- 优先排对齐值大的字段：
int64、string、[]byte、interface{}（对齐值8）→int32（4）→int16（2）→bool/uint8（1） - 同对齐值字段尽量连续，避免被小字段割裂。例如两个
int64之间插一个bool，会打断8字节连续空间，导致额外7字节padding - 末尾小字段后可手动补
_ [N]byte凑整，但仅当明确需要控制对齐时才用，多数场景靠排序就够了
空结构体struct{}真的零开销吗
是，unsafe.Sizeof(struct{}{}) == 0，但它不等于“无影响”。作为字段时它不占空间，但作为map value或channel元素，会触发底层分配策略变化——此时它省的是堆分配而非栈空间。
- 放在结构体开头或中间，不影响后续字段偏移（因为不占位）
- 但若结构体只含
struct{}和一个int64，总大小仍是8（不是0+8=8再对齐），因为整体对齐值由int64决定 - 常见误用：以为
struct{ _ struct{}; data int64 }能“压缩”data起始位置——其实data仍从0开始，和没写_ struct{}一样
ID int64从第三位提到第一位，也可能让结构体从24字节降到16字节——这种变化在高频分配场景（如网络包解析、缓存对象）里直接反映为GC压力和带宽消耗。真正要盯住的，从来不是单个字段，而是字段之间的“间隙”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
