Go slice扩容不直接产生外部碎片，因其每次分配连续内存块并由runtime按size class对齐复用；但扩容后容量×元素大小常无法对齐档位，导致内部碎片，并因频繁分配/释放、全量拷贝及旧数组变不可达对象而显著加剧GC压力。
Go 的 slice 扩容本身不直接制造外部碎片，但会显著加剧 runtime 内存分配器的内部碎片和 GC 压力——尤其当大量中等大小、生命周期不一的 slice 频繁申请/释放时。
为什么扩容不产生外部碎片，却让 GC 更累？
Go runtime 的内存分配器按 size class（如 8/16/32/48/64… 字节档位）管理堆内存。每次 growslice 都调用 mallocgc 分配一块连续新数组，旧数组交由 GC 回收。这本身不会割裂空闲内存块，所以不造成外部碎片。
但问题出在：扩容后的实际分配尺寸必须向上对齐到最近的 size class。比如 make([]int64, 0, 1025) 理论需 8200 字节，而 runtime 可能分配 8320B 或 9216B，多出来的就是内部碎片。这些“多占少用”的块越多，各 size class 的空闲链表就越难被交叉复用。
GC 压力上升的关键路径是：append → growslice → 新分配 + 全量 memmove + 旧底层数组变成不可达对象 → 下一轮 GC 必须扫描并清扫它。
哪些扩容行为会让 GC 频次和耗时飙升？
以下场景在 pprof 中常表现为 runtime.mallocgc 占比异常高、heap profile 显示大量 []uint8 或 []struct{...} 分配峰值：
- HTTP handler 中每请求都
buf := make([]byte, 0, 2048)，但实际只写入 300 字节 → 每次都分配 2KB+，却只用零头 - 混用多种元素大小的切片：
[]int、[32]byte、User（含指针字段），它们的扩容路径错开，导致不同 size class 的空闲块长期闲置 - 缓存类 slice 长期持有虚高 cap：
cache := make([]Item, 0, 512)，但实际长度常年在 3~20 波动 → 底层数组占着大块内存却不被复用，还拖慢 GC 标记（因含指针）
预分配不是银弹，但它是唯一可控的缓解手段
预分配不能消除内部碎片，但能砍掉绝大多数不必要的扩容次数和随之而来的拷贝与垃圾对象。关键在于：容量要贴近真实使用上限，而非拍脑袋设大值。
有效做法包括：
- 已知长度时，直接用
make([]T, 0, len(src))；例如解析 JSON 数组前先读取长度字段 - 有上下文边界时，留合理余量：
make([]byte, 0, headerLen + 512)，避免因小余量反复触发 1.25 倍扩容 - 批量处理中按统计均值上取整到 2 的幂或常见 size class 边界（如 256、512、1024），比盲目用
make([]T, 0)少 90% 以上拷贝
注意：make([]T, N) 和 make([]T, 0, N) 完全不同——前者初始化 N 个零值并设 len == cap == N，后者只预留空间，len == 0，更轻量。
最隐蔽的坑：cap 泄漏让大数组“假死”
这不是扩容导致的问题，但和扩容共存于同一 slice 生命周期里，极易被忽略：
buf := make([]byte, 0, 1<br><code>small := buf[:10]return small
表面上只返回 10 字节，但 GC 必须保留整个 1MB 底层数组——因为 small 的 Data 指针仍指向原起点。这块内存会进入老生代，每次 GC 都要扫描，且无法被其他分配复用。
安全提取必须切断引用：safe := append([]byte{}, small...) 或 bytes.Clone(small)（Go 1.20+）。别信 s[:] 或 s[0:len(s)] 是“重置”，它们不改 Data。
