结构体字段顺序直接影响内存占用，大字段应前置以减少填充，需用unsafe.sizeof和offsetof验证实际布局，嵌套结构体会继承最大子字段对齐值，优化在高频分配场景效果显著。
struct字段顺序直接影响内存占用大小
Go结构体的字段声明顺序不是无关紧要的装饰，它直接决定编译器插入多少padding字节。同一个字段组合，int64放前面和放中间，unsafe.Sizeof返回值可能差出50%。
- 大字段（
int64、string、指针）优先前置，让后续小字段能“塞进”其尾部空隙 - 避免把
bool或int8夹在两个大字段之间——这会强制插入大量填充 - 同尺寸字段尽量归组，比如多个
int32挨着写，减少跨边界错位
用unsafe.Sizeof和unsafe.Offsetof验证真实布局
别猜，实测。仅靠字段类型加总得出的“理论大小”在Go里基本没参考价值，必须用unsafe包看运行时实际分配。
-
unsafe.Sizeof(T{})返回结构体总字节数（含所有填充） -
unsafe.Offsetof(t.field)告诉你每个字段从结构体起始地址偏移多少，一眼看出哪段是填充 - 注意：
unsafe包只用于诊断，不能用于生产逻辑，且需导入"unsafe"
嵌套结构体对齐会继承最大子字段对齐值
当你把一个结构体作为另一个结构体的字段时，它的整体对齐要求会被提升到其内部最大字段的对齐值，并影响外层布局。
- 例如内嵌
type Inner struct { X int64; Y bool }，其Alignof为8，即使外层全是int32字段，也会被按8字节边界对齐 - 如果嵌套结构体本身未优化（比如字段乱序），它的填充会“传染”给外层，放大浪费
- 想最小化影响，要么扁平化字段，要么确保嵌套结构体自身已按大小降序排列
对齐优化在高频分配场景下效果最明显
单个结构体省下8字节看起来微不足道，但当它被用于make([]T, 1e6)或作为map value高频创建时，内存压力会立刻显现。
- GC压力降低：更紧凑的布局意味着更少的页分配、更低的标记开销
- 缓存行利用率提升：一个CPU缓存行（通常64字节）能塞进更多有效字段，减少cache miss
- 注意陷阱：过度优化可能牺牲可读性；若结构体主要用于序列化而非内存密集计算，优先保证清晰性
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
