unsafe.sizeof 和 unsafe.offsetof 是验证 go 内存对齐的核心工具：sizeof 揭示填充导致的结构体膨胀，offsetof 暴露字段真实偏移，二者结合可精准定位填充位置与原因，并指导字段顺序优化以提升缓存效率和 gc 性能。
unsafe.Sizeof 和 unsafe.Offsetof 是理解 Go 内存对齐最直接的工具，不需要猜、不用查文档翻源码，跑几行代码就能验证规则是否生效。
用 unsafe.Sizeof 看结构体总大小是否被“撑大”
结构体大小不是字段字节数简单相加，而是受最大字段对齐值约束。比如：
type S1 struct {
a uint8 // 1 byte, align=1
b int64 // 8 bytes, align=8
c uint32 // 4 bytes, align=4
}
fmt.Println(unsafe.Sizeof(S1{})) // 输出 24
原因：最大对齐值是 int64 的 8，所以整体大小必须是 8 的倍数；字段 b 要求偏移量 % 8 == 0，a 占 1 字节后，编译器插入 7 字节填充，b 才能从 offset=8 开始；后续再补 4 字节对齐尾部。
- 只要
unsafe.Sizeof结果 > 字段字节和，就说明有填充 - 结果一定是结构体中最大字段
unsafe.Alignof值的整数倍 - 不同字段顺序会改变填充位置和总量，
unsafe.Sizeof是最敏感的“对齐探测器”
用 unsafe.Offsetof 查每个字段真实起始位置
字段偏移量不等于前面字段长度之和，而是受自身对齐要求限制。例如：
type S2 struct {
a uint8 // offset=0
b uint32 // offset=4（不是 1），因为 b 要求 %4==0
c uint64 // offset=8（不是 5），因为 c 要求 %8==0
}
运行 unsafe.Offsetof(S2{}.b) 得到 4，unsafe.Offsetof(S2{}.c) 得到 8 —— 这就是编译器插入填充的铁证。
-
unsafe.Offsetof返回的是从结构体起始地址到该字段首字节的距离 - 如果某个字段的 offset 不等于前序字段总长，中间必然有填充
- 嵌套结构体字段的 offset 也遵循同样规则，可逐层验证
用 unsafe.Alignof 确认每个字段的对齐边界
对齐值不是类型长度，而是平台和类型共同决定的。常见规律：
-
uint8/bool→unsafe.Alignof= 1 -
uint16/int32→ 通常为 4（amd64 下） -
uint64/int64/string/*T→ 通常为 8 - 空结构体
struct{}→unsafe.Alignof= 1，但unsafe.Sizeof= 0
注意：unsafe.Alignof 返回的是该类型变量的自然对齐要求，不是结构体整体对齐值。结构体整体对齐值 = 所有字段 unsafe.Alignof 的最大值。
字段顺序调优时，别只看 Sizeof，要同步验证 Offsetof
把大字段放前面确实常减少填充，但容易忽略嵌套或指针字段带来的隐性对齐压力。例如：
type Bad struct {
a uint8 // offset=0
b string // offset=8（因 string.align=8）
c [2]int32 // offset=24（因 b 占 16 字节，c 需 %4==0，24%4==0）
}
type Good struct {
b string // offset=0
c [2]int32 // offset=16（16%4==0）
a uint8 // offset=24（24%1==0）
}
两者 unsafe.Sizeof 可能相同，但字段访问局部性不同；unsafe.Offsetof 能暴露谁在“开头拥挤”，谁在“结尾松散”。实际优化时，必须两个函数一起用。
真正难的不是算出对齐结果，而是意识到：字段顺序影响的不只是内存占用，还有 CPU cache line 利用率和 GC 扫描效率。这些没法靠单个函数一眼看出，得结合场景反复测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
