旧底层数组真正被GC回收的时机是其所有引用（包括子切片等）全部消失、变为GC Roots不可达时，经可达性分析判定为垃圾后，在下一轮GC周期中被回收。
旧底层数组什么时候真正被 GC 回收？
旧底层数组是否回收，不取决于你有没有 append、也不取决于你有没有把原 slice 设为 nil，而只取决于它的引用计数是否降为 0。只要还有任意一个变量（比如子切片 s2 := s[3:5]）指向它，这块内存就继续活着。
常见误判场景：
- 你以为
s = nil就释放了底层数组 —— 错，s只是结构体变量被清空，底层数组还在 - 你用
s = s[:0]截断长度 —— 这只是把len归零，cap和底层数组完全没动 - 你看到
unsafe.Pointer(&s[0])地址变了，就以为旧数组“已失效” —— 地址变只说明新 slice 指向新内存，旧数组是否回收仍看引用
为什么扩容后 GC 压力会明显升高？
每次 growslice 触发扩容，都要分配一块新内存，并用 memmove 把全部现有元素拷过去。旧底层数组立刻变成不可达对象（前提是无其他引用），但不会立刻回收 —— 它得等下一轮 GC 周期扫描并标记为可回收。
高频小 slice 扩容时，问题更突出：
- 每轮
append都产生一个待回收的小堆对象，GC 频次被迫上升 - 大量短生命周期的底层数组在 mcache/mcentral 间频繁进出，加剧分配器压力
- 若元素含指针（如
[]*string），GC 还要额外扫描指针字段，开销翻倍
如何主动切断引用，帮 GC 快点干活？
没有魔法函数能“强制立即回收”，但你可以让底层数组尽快变成 GC 可见的垃圾：
- 把所有持有该底层数组的变量（包括子切片、函数参数传递后的副本）都设为
nil - 用
copy构造独立副本：newS := make([]int, len(s)); copy(newS, s)，之后原s和所有子切片可安全丢弃 - 避免长期持有子切片：比如循环中写
item := s[i]没问题，但sub := s[i:i+1]就可能意外延长底层数组寿命
注意：runtime.GC() 是调试手段，生产环境别调用；GC 步调由 runtime 自动调节，人为干预反而扰动调度。
预分配容量真能绕过这些麻烦吗？
能，而且是最直接有效的办法。预分配跳过了绝大多数 growslice 调用，也就绕开了拷贝、新分配、旧数组滞留这一整条链路。
但要注意两个现实约束：
- 预估过大（比如
make([]byte, 0, 1）会造成内部碎片：8MB 内存按 size class 对齐后实际可能占 8.3MB，多出的 300KB 白占不用 - 预估过小（比如
make([]int, 0, 999)，后续要塞 1000 个）仍会触发一次扩容，且这次扩容从 999→2048，浪费比从 1024→1280 更严重 - 对不确定长度的流式数据（如网络包解析），硬预分配不现实，此时应搭配
sync.Pool复用 slice，而非依赖单次扩容
真正容易被忽略的是：哪怕你写了 make([]T, 0, N)，只要后续有任意一次 s = s[2:4] 这类截取，再传给别的函数，那个函数里再 append，照样可能触发扩容和旧数组滞留 —— 扩容风险藏在共享底层数组这个行为里，不在 append 这一行代码本身。
