小结构体是否“小”取决于其落入的 size class 档位，由字段顺序、指针逃逸和 go 版本共同决定；真实分配大小需查当前 go 版本的 sizeclasses.go，而非仅看 unsafe.sizeof(t{})。
直接结论：别只盯着 unsafe.sizeof，小结构体是否“小”，取决于它最终落在哪个 size class，而这个档位由字段顺序、指针逃逸、go 版本共同决定；高频创建时，单靠调整字段顺序往往不够，必须结合 sync.pool 或栈上分配（避免逃逸）。
怎么查某个 struct 实际走哪个 size class
不能只看 unsafe.Sizeof(T{}) —— 它返回的是紧凑布局下的理论最小值，不是 runtime 真实分配的大小。真实分配按 Go 运行时硬编码的 sizeclasses.go 分档（共 67+ 档），每个档位对应一个上限字节数（如 class 4 上限是 32 字节，17–32 字节对象全按 32 字节分配）。
- 查法：算出
unsafe.Sizeof(T{})，比如得到 25，然后去你当前 Go 版本的src/runtime/sizeclasses.go里找第一个 ≥ 25 的上限值（Go 1.26 中 class 6 是 48B，class 5 是 32B → 所以 25B 落在 class 5，实际分配 32 字节） - 注意：如果结构体含指针且逃逸到堆上，才走这套逻辑；若全程栈分配（
go tool compile -gcflags="-m -l"显示movetoheap没出现），就完全不经过mcache和size class - 常见误判：struct{a byte; b bool} 理论 2 字节，但因 tiny allocator 合并策略，大概率被塞进同一个 16 字节块，GC 扫描时整个块算 live，改一个字段等于“拖累”其余 14 字节
字段顺序怎么调才真省内存
目标不是“减少 padding”，而是“压低 size class 档位”。对齐规则只是手段，size class 边界才是关键约束。
- 把大字段（
int64、string、指针）放前面，小字段（byte、bool、int32）集中放后面，更容易让总大小卡在 class 边界内（例如从 33 字节掉回 32 字节，跳过 class 6 直接进 class 5） - 反例：struct{a byte; b int64; c bool} →
unsafe.Sizeof= 24，但 class 6 上限是 48，没用；若改成 struct{b int64; a byte; c bool}，还是 24，但若后续加个int32，前者可能涨到 32（仍卡 class 5），后者可能直接跳到 40（进 class 6） - 真正起效的边界点：16B、32B、48B、64B……这些才是 size class 切口，不是 8B 或 16B 对齐本身
为什么预分配 slice 不够，还得上 sync.Pool
预分配解决的是切片底层数组反复扩容的开销，但对“每个元素都是独立小 struct”的场景，它不减少 struct 本身的分配次数——每次 append 仍要 new 一个 struct 实例。
-
sync.Pool复用的是 struct 实例本身，不是底层数组；适合生命周期明确、可重置的场景（如 HTTP 中间件里的RequestCtx） - 注意 reset 成员：Pool.Get 返回的对象可能残留旧数据，必须显式清零或重置字段（尤其含指针或 slice 的 struct），否则引发 data race 或 GC 无法回收
- 别池化带长生命周期引用的 struct：比如 struct 里存了
*http.Request或闭包，Pool 会阻止它们及时释放，反而加剧 GC 压力
逃逸分析比 size class 更优先
所有 size class 优化都建立在一个前提上：该 struct 确实逃逸到了堆。如果它能留在栈上，就根本绕过 mcache/mcentral/size class 全套机制。
- 用
go tool compile -gcflags="-m -l"看关键函数：没有... escapes to heap就说明栈分配成功 - 常见逃逸诱因：作为返回值传出函数、赋值给 interface{}、传给 variadic 函数、取地址后存入全局变量或 map/slice —— 这些比字段顺序影响更大
- 技巧：用局部变量 + 直接传参代替中间 struct 构造；或把小 struct 拆成独立参数（如
fn(id int64, name string)比fn(req *Request)更不容易逃逸）
最常被忽略的一点：Go 1.22+ 新增了更多 size class（如 class 64 处理 1MB+ 对象），但旧版分析工具（比如某些 IDE 插件或在线 size class 查表器）仍按老规则匹配，会导致档位误判；务必用项目当前 Go 版本的 sizeclasses.go 对照。
