unsafe.sizeof返回结构体实际内存占用（含padding），非字段大小之和；差值≥4字节即存在填充，需配合unsafe.offsetof定位具体位置。
unsafe.Sizeof 返回的是结构体**实际内存占用字节数**，不是字段大小之和，也不是“紧凑排列”后的理论值——它已经把 padding 算进去了，但不告诉你 padding 在哪。想省空间，不能只看这个数，得配合 unsafe.Offsetof 定位填充位置。
怎么用 unsafe.Sizeof 快速判断结构体有没有被 padding “坑”
直接比对两个值：unsafe.Sizeof(YourStruct{}) 和所有字段 unsafe.Sizeof 之和。差值 ≥ 4 字节，基本就是 padding 在作祟。
- 常见信号：
unsafe.Sizeof返回 24，但字段加起来才 11 → 多出的 13 字节全是填充 - 结构体末尾多出 4 或 7 字节 → 很可能是整体对齐补足（最大字段对齐值为 8，总大小必须是 8 的倍数）
- 嵌套 struct 导致外层
unsafe.Sizeof突然跳变（比如内嵌含int64的 struct，外层多出 8 字节）→ 内嵌 struct 整体按自身最大对齐值参与布局，不是拆开算
为什么字段重排后 unsafe.Sizeof 不降反升
排序本身不等于优化成功。字段顺序只是影响 padding 的一个变量，不是万能解药。
- 嵌套 struct 自身有对齐开销：
struct{ x byte; y int64 }单独占 16 字节，塞进外层时，它整个要对齐到 8 字节边界，不是按x和y单独算 - 导出字段被
json/gob/ORM 依赖：改顺序可能导致json.Unmarshal映射错位，或 GORM 找不到列 - cgo 场景下 C struct 和 Go struct 对齐策略不一致：
C.sizeof_struct_xxx和unsafe.Sizeof相等也不代表安全，必须用 C 端真实 size 对比验证
哪些场景下 unsafe.Sizeof 值真值得较真
不是所有结构体都值得调。重点盯这几类：
-
[]MyStruct切片元素类型：节省 1 字节 × 百万条 = 1MB - 高频创建/销毁对象（如网络协议解析中的
PacketHeader、HTTP 中间件上下文） - 缓存敏感路径上的热结构体：哪怕
unsafe.Sizeof没变，字段重排后若导致热字段跨 cache line，性能损失远超几字节填充
真正容易被忽略的点是：字段重排后，unsafe.Offsetof 可能“跳变”，尤其含数组或嵌入 struct 时。别脑算，直接打印验证更可靠；而序列化契约、cgo ABI、缓存行对齐这三者冲突时，unsafe.Sizeof 最小从来不是第一优先级。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
