go结构体内存占用受编译器填充字节影响，字段顺序决定padding位置与总量；大对齐字段（如int64、string）前置可减少填充；结构体总大小必为最大字段对齐值的整数倍，以保证数组元素自然对齐。
Go结构体的内存占用不是字段大小简单相加，而是受编译器自动插入填充字节（padding）影响的结果——这直接决定你分配的 struct 是 32 字节还是 48 字节，哪怕字段完全一样。
struct 字段顺序如何影响 unsafe.Sizeof 结果
字段排列顺序决定了填充位置和总量。编译器按声明顺序依次放置字段，并在每个字段前插入必要 padding，使其地址满足自身对齐要求。
-
int64要求 8 字节对齐，若前一个字段结束位置不是 8 的倍数，就补空字节 -
string实际是struct{ data *byte; len int }，指针部分需 8 字节对齐（64 位系统） - 把大对齐字段（如
int64、string、指针）往前放，小字段（int8、bool）往后集中，能显著减少 padding
比如：type A { a int8; b int64; c int32 } 占 24 字节；而 type B { a int8; c int32; b int64 } 占 32 字节——仅因 int64 被挤到后面，前面被迫补 4 字节对齐空隙。
为什么 unsafe.Sizeof 返回值总是结构体整体对齐值的整数倍
结构体总大小必须被其“最大字段对齐值”整除。例如含 int64 和 int32 的 struct，整体对齐值为 8，所以最终大小一定是 8 的倍数。
- 即使所有字段加起来只有 13 字节，
unsafe.Sizeof也可能返回 16 - 这是为了保证数组中每个元素都能自然对齐：若 struct 不按自身对齐值补齐，第二个元素的首地址就不满足第一个字段的对齐要求
- 这种尾部 padding 不影响单个实例，但对 slice 或 map value 等批量使用场景有实际开销
哪些类型在 64 位 Go 中默认 8 字节对齐
不是所有“大类型”都对齐到 8 字节，也不是所有 8 字节类型都强制 8 对齐——得看底层实现。
- 明确 8 字节对齐的：所有指针（包括
*T、func()、map[K]V、chan T）、int64、uint64、float64、complex128、uintptr -
string和interface{}因含指针字段，也按 8 字节对齐 - 注意：
[8]byte是 1 字节对齐（因为元素是byte），而[8]int64整体对齐值仍是 8
混淆这点容易误判 padding 位置——比如以为 [16]byte 会触发 16 字节对齐，其实不会。
用 go tool compile -gcflags="-m -l" 验证字段偏移
逃逸分析输出里常带字段偏移信息，但更直接的是用 unsafe.Offsetof 手动检查。
-
unsafe.Offsetof(s.b)能告诉你字段b实际从 struct 起始偏移多少字节 - 结合
unsafe.Sizeof和各字段 offset，就能反推出每段 padding 长度 - 别依赖 IDE 或文档推测——不同 Go 版本或 GOARCH 下对齐规则可能微调（比如 ARM64 对某些类型对齐更严格）
真正容易被忽略的，是 struct 嵌套时的“双重对齐”：外层 struct 的对齐要求，既取决于内层字段，也取决于内层 struct 自身的对齐值——它本身就是一个黑盒对齐单元，不是字段简单展开。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
