struct{a int8; b int64}比struct{b int64; a int8}多占7字节，因前者在int8后需7字节填充使int64对齐，后者无此填充，但两者总大小均为16字节；差异在数组或嵌套场景中被放大。
为什么 struct{a int8; b int64} 比 struct{b int64; a int8} 多占 7 字节
Go 编译器会按字段类型对齐要求，在字段间插入填充字节（padding），让每个字段的起始地址满足其对齐约束。比如 int64 要求 8 字节对齐，int8 只要 1 字节对齐。
实操建议：
-
struct{a int8; b int64}：首字段a占 1 字节，接着必须跳过 7 字节才能让b对齐到第 8 字节位置，总大小变成 16 字节（1 + 7 + 8） -
struct{b int64; a int8}：b占前 8 字节，a紧跟其后占第 9 字节，结构体总大小为 16 字节（但末尾无额外 padding）——等等，这不都 16？别急，看下一个副标题 - 真正差异在数组或嵌套场景：
[]T中每个元素独立对齐，字段顺序影响单个元素大小，进而放大内存浪费
用 unsafe.Offsetof 和 unsafe.Sizeof 查结构体真实布局
光看字段类型猜 padding 容易错，尤其含指针、slice、interface{} 或嵌套 struct 时。必须实测。
常见错误现象：以为字段顺序无关紧要，结果线上服务 GC 压力突增、缓存命中率下降。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 用
unsafe.Sizeof(T{})看整体大小 - 用
unsafe.Offsetof(t.a)、unsafe.Offsetof(t.b)精确查每个字段偏移 - 注意：这些函数只接受字段名，不能传表达式；且必须在包内调用（非反射）
- 示例：
type S struct{a int8; b int64; c int16}<br>fmt.Println(unsafe.Sizeof(S{})) // 输出 24<br>fmt.Println(unsafe.Offsetof(S{}.b)) // 输出 8<br>fmt.Println(unsafe.Offsetof(S{}.c)) // 输出 16
结构体字段重排能省多少内存：真实案例中的 20%～40%
不是所有重排都有效，效果取决于字段类型组合和数量。小结构体（≤16 字节）优化最明显；大结构体中 padding 占比下降，但绝对值可能更大。
使用场景：
- 高频创建的对象（如 HTTP 请求上下文、数据库行结构体）
- 大 slice 存储（
[]User，百万级时差几 MB 就是几十 MB） - 需要与 C 互操作或 mmap 文件映射的结构体（此时 padding 还涉及 ABI 兼容性）
性能影响：
- 减少内存占用 → 更少 GC 扫描对象 → 降低 STW 时间
- 更紧凑布局 → CPU cache line 利用率提升（尤其遍历 slice 时）
- 但重排本身不改变字段访问速度，Go 的字段访问始终是编译期计算偏移，无运行时开销
哪些类型对齐值是“隐藏陷阱”
多数人记得 int64 是 8，int32 是 4，但容易忽略以下情况：
-
[16]byte对齐值是 1，但[16]int64对齐值是 8 —— 数组对齐值 = 元素对齐值 - struct 的对齐值 = 其所有字段对齐值的最大值（不是总和！）
-
string和slice在 runtime 中是 2 字段结构体（ptr + len），各自对齐值为uintptr大小（通常 8），所以含它们的 struct 往往以 8 对齐打底 - 接口类型
interface{}实际是 2 字段（type ptr + data ptr），对齐值也是 8；但它在 struct 中的位置会影响后续字段是否被“推远”
容易踩的坑：用 reflect.TypeOf(T{}).Align() 查对齐值，但该值仅反映 struct 整体，无法告诉你字段间 padding 分布 —— 还得靠 Offsetof。
复杂点在于，对齐规则在 32 位系统上会变（如 int64 对齐值可能降为 4），而 Go 默认已不支持 32 位 x86，但 ARM32 仍存在；跨平台时务必实测。
