结构体优化需先按对齐值降序排列字段以减少填充，再根据 unsafe.sizeof 结果决定传值或指针：≤32 字节且只读优先值传，>64 字节优先指针传，并用 -gcflags="-m" 验证逃逸。
结构体太大时值传参会拷贝多少内存
直接看 unsafe.Sizeof 结果，别猜。比如一个含 [1000]int64 的结构体，unsafe.Sizeof 返回 8000 字节，那每次值传参就在栈上拷贝 8KB —— 不是“可能慢”，是实打实的开销。
- 小结构体（≤16 字节）：值传参通常比指针还快，编译器可能用寄存器优化，无需堆逃逸
- 含
slice/map/string的结构体：只拷贝 header（24 或 32 字节），不拷贝底层数组，但共享数据，要注意并发读写安全 - 含大数组（如
[8192]byte）或嵌套大结构体：必须警惕，拷贝量 = 整个内存块大小
为什么先调字段顺序，而不是直接上指针
字段顺序不对，哪怕你传指针，结构体本身仍浪费空间 —— 堆上分配的对象也会带着冗余填充字节，GC 扫描、缓存行加载都更重。
-
int64（8 字节对齐）、string（16 字节但对齐值为 8）、int32（4 字节对齐）、bool（1 字节对齐）—— 按对齐值降序排，能显著减少填充 - 错误示例：
type Bad { a bool; b int64; c int32 }→a后强制补 7 字节才能让b对齐，总大小膨胀 - 正确示例：
type Good { b int64; c int32; a bool }→ 编译器只需在末尾补 3 字节，总大小更紧凑 - 验证方式：
unsafe.Sizeof和unsafe.Offsetof配合看字段偏移，确认是否“紧贴”
指针传参后结构体反而更大？逃逸分析没跑过
传 *T 不等于省内存；如果 T 本身因字段排列差而臃肿，或者指针触发逃逸，结果可能是堆上存一个更胖的 T，还带 GC 开销。
- 常见逃逸点：
return &t、把*T存进map或切片、被 goroutine 捕获、赋值给接口类型（尤其含方法） - 验证命令：
go build -gcflags="-m -l"，搜escapes to heap—— 如果出现，说明你没省内存，只是换地方花了 - 真正要做的：先用
unsafe.Sizeof把结构体压到最小，再决定传值 or 传指针；若高频调用且 >64 字节，优先指针；若只读且 ≤32 字节，值传参往往更干净
字段排序 + 指针传参的组合实操建议
这不是玄学，是两步确定性动作：先减体积，再控传递方式。中间跳任何一步，优化就打折。
- 第一步：用
unsafe.Alignof查每个字段对齐值，按从大到小重排字段（int64、string、int32、bool这类） - 第二步：对优化后的结构体跑
unsafe.Sizeof，若仍 >64 字节，函数参数改用*T；若 ≤32 字节且无修改需求，保持值传参 - 第三步（可选）：对关键路径加
-gcflags="-m"确认无意外逃逸；有则检查是否存指针到全局 map、是否返回局部地址 - 注意：
sync.Mutex等不可拷贝字段会强制要求指针传参，但它们本身也影响对齐，需一并纳入排序考量
字段顺序错一位，填充字节可能多出十几个；指针传参没逃逸分析兜底，堆上对象照样胖。这两件事必须一起做，缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
