Go结构体大小不是字段字节数之和，因为编译器会插入填充字节（padding）以满足内存对齐要求：每个字段起始地址必须是其自身对齐值的整数倍，结构体总大小必须是最大字段对齐值的整数倍；bool/int8对齐值为1，int32/float32为4，int64/指针等为8；需用unsafe.Sizeof和unsafe.Offsetof验证真实布局，字段顺序按对齐值降序（8→4→2→1）排列可最小化padding。
Go结构体大小为什么不是字段字节数之和
因为编译器会插入填充字节（padding）来满足内存对齐要求，不是你写多少字节就占多少字节。CPU读取未对齐数据时可能要两次访存，性能掉30%以上，Go宁可多占点内存也要保证对齐。
关键判断依据是：每个字段起始地址必须是其自身对齐值的整数倍；结构体总大小必须是其最大字段对齐值的整数倍。
-
bool、int8对齐值为 1，可从任意地址开始 -
int32、float32对齐值为 4，起始地址必须是 4 的倍数 -
int64、float64、指针类型对齐值为 8（在64位系统上） - 结构体整体对齐值 = 所有字段对齐值的最大值
如何用 unsafe.Sizeof 和 unsafe.Offsetof 验证对齐效果
别猜，直接看。这两个函数能暴露编译器真实布局，比文档更可靠。
示例：
立即学习“go语言免费学习笔记（深入）”；
type S struct {
a bool // offset 0
b int64 // offset 8（不是1！因为b要8字节对齐）
c int32 // offset 16（不是16+1=17！因为c要4字节对齐，16刚好满足）
}
fmt.Println(unsafe.Sizeof(S{})) // 输出 24
fmt.Println(unsafe.Offsetof(S{}.a)) // 0
fmt.Println(unsafe.Offsetof(S{}.b)) // 8
fmt.Println(unsafe.Offsetof(S{}.c)) // 16
-
unsafe.Sizeof返回的是含 padding 的实际内存占用 -
unsafe.Offsetof显示每个字段真实偏移，能看出哪段被 pad 了 - 注意：
unsafe操作不参与逃逸分析，但仅用于观察布局是安全的
字段顺序调优：怎么排能让结构体更小
把大字段放前面，小字段往后堆——这是最简单有效的优化手段，能显著减少 padding。
反例：BadStruct 含 bool + int64 + bool，大小是 24 字节；正例：GoodStruct 把 int64 放第一，两个 bool 紧跟其后，大小压到 16 字节。
- 优先按对齐值降序排列字段：8 → 4 → 2 → 1
- 同类对齐值的字段可以相邻放置，不会新增 padding
- 如果字段语义强绑定（比如
width和height总是一起用），不要为省1字节强行拆开，可读性优先 - 切片/指针字段本身是 8 字节（64位），但它们指向的数据不在结构体内，不影响本体对齐
cgo 或硬件交互时为什么必须手动控制对齐
Go默认对齐规则和C不完全一致，尤其在32位平台或嵌入式场景下，字段错位会导致读写脏数据甚至 panic。
典型场景：C结构体定义了 char a; int b;，期望总长 8 字节（1字节+3字节pad+4字节），但Go若按自然顺序生成，可能变成 1+7+4=12 字节，传给C就全乱了。
- 用显式填充字段（如
_ [3]byte）强制对齐边界 - 加
//go:packed注释不起作用，Go 不支持#pragma pack - 跨平台时特别注意：
int在32位系统对齐值是4，在64位是8，建议统一用int32/int64 - 驱动开发中寄存器映射结构体必须严格匹配硬件要求，差1字节就可能触发 bus error
对齐不是“写完再优化”的事后技巧，而是设计结构体时就要想清楚的事——尤其当它出现在高频路径、百万级对象或与外部系统对接的边界上。
