make([]byte, 0, n) 更省内存，因预分配容量但不初始化底层数组，避免无意义清零及GC追踪开销；适用于后续立即用 copy() 或 append() 填充真实数据的场景。
为什么 make([]byte, 0, n) 比 make([]byte, n) 更省内存
预分配切片容量但不初始化底层数组，能避免无意义的零值填充——尤其在后续立即用 copy() 或 append() 填充真实数据时。make([]byte, n) 会把整块内存清零，而 GC 仍需追踪这 n 字节的生命周期；若只是临时拼接字符串或解析二进制流，清零纯属浪费。
实操建议：
- 读取文件或网络包时，优先用
make([]byte, 0, expectedSize)+io.ReadFull()或bytes.Buffer.Grow() - 避免对大切片反复
append()导致多次扩容重分配；估算上限后一次性预分配 - 注意：如果后续逻辑依赖元素初始为零（如计数器数组），就不能跳过初始化
哪些 struct 字段顺序会让内存占用翻倍
Go 的 struct 内存布局遵循字段按声明顺序排列、并按自身对齐要求填充的规则。例如 bool（1 字节）后面紧跟 int64（8 字节），编译器会在中间插入 7 字节 padding，使单个 struct 多占 7 字节；10 万实例就是 700KB 浪费。
实操建议：
- 把相同大小的字段归类并按从大到小排序：
int64、float64、string→int32、float32→int16→bool、byte - 用
go tool compile -S查看汇编输出里的字段偏移，或用github.com/bradfitz/go4/structlayout工具分析填充率 - 慎用
unsafe.Offsetof强行绕过对齐——破坏可移植性且易引发 panic
sync.Pool 不是缓存，滥用反而增加 GC 压力
sync.Pool 的核心设计目标是复用临时对象以减少堆分配频次，但它不保证对象存活，GC 会无条件清空所有池中对象。把它当长期缓存用，等于主动制造“分配→放入池→被 GC 清掉→下次再分配”的循环。
