make([]int, 0, 100) 更省内存，因其仅分配容量而不初始化底层数组，不提交物理内存页；而 make([]int, 100) 立即分配并清零800字节，强制占用实际内存页。
为什么 make([]int, 0, 100) 比 make([]int, 100) 更省内存？
关键不在“分配多少”，而在“是否立即占用实际内存页”。make([]int, 100) 会立刻申请并清零 100 个 int 的空间（800 字节），即使后续只写前 5 个；而 make([]int, 0, 100) 只分配底层数组容量，切片长度为 0，不触发初始化——Go 运行时不会为未使用的容量提前提交物理内存页。
实操建议：
- 预估容量且写入是逐步发生的场景（如解析 JSON 数组、收集日志条目），优先用
make(T, 0, cap) - 若后续要频繁
append，但初始长度不确定，避免用make(T, n)再append——这会触发一次不必要的扩容复制 - 注意：
make([]byte, 0, n)是构建可增长缓冲区的标准写法，bytes.Buffer内部正是这么做的
哪些结构体字段会导致隐式内存浪费？
Go 的结构体字段按对齐规则填充，小字段排布不当会引入大量 padding。例如：struct{ bool; int64; bool } 在 64 位系统上实际占 24 字节（bool 占 1，但紧接的 int64 要求 8 字节对齐，导致前两个字段间插入 7 字节 padding；末尾 bool 又触发 7 字节 padding）。
实操建议：
- 把大字段（
int64、指针、struct）放在前面，小字段（bool、int8、byte）集中放后面 - 用
go tool compile -gcflags="-m" main.go查看编译器是否提示 “can be inlined” 或 “escapes to heap”，间接反映字段布局是否引发逃逸 - 对高频创建的小结构体（如链表节点、缓存 entry），用
unsafe.Sizeof验证实际大小，别信直觉
sync.Pool 真的能降低 GC 压力吗？什么时候不该用？
能，但仅限于“临时、可复用、生命周期短”的对象（如 []byte 缓冲、JSON 解析器实例）。它绕过 GC，由运行时在 GC 前清理未被取走的对象。但滥用反而增加开销甚至泄漏。
