底层数组在所有引用它的 slice 均不可达且运行时引用计数归零时才被 GC 回收；常见陷阱是子切片隐式持有大数组导致内存“钉住”，主动释放需用 copy、append(nil) 或显式置 nil 并清空。
底层数组不会随 slice 变量消失而立即释放，只要还有任意一个 slice 结构体持有它的 array 指针，这块内存就继续存活。
底层数组什么时候真正被回收？
Go 运行时用引用计数跟踪底层数组：每个指向同一块底层数组的 slice 都算一次引用。只有当所有相关 slice 都不再可达（比如超出作用域、被赋值为 nil、或被 GC 标记为不可达），且引用计数归零时，GC 才会回收那块数组内存。
常见错误现象：
- 从大
slice切出小sub，然后丢弃原slice，但sub仍持有原底层数组首地址 → 整个大数组无法释放 - 函数返回一个从入参
slice切出来的子切片，调用方保留该返回值 → 入参背后的大数组被意外“钉住”
如何主动切断对底层数组的引用？
想让底层数组尽快释放，核心是让所有共享它的 slice 都不再指向它。常用方法：
- 用
copy分离：newS := make([]byte, len(oldS)); copy(newS, oldS)—— 新分配独立底层数组 - 用
append强制重分配：newS := append([]T(nil), oldS...)——nil切片的cap是 0，append必走新分配路径 - 手动置
nil并清空：s = nil; s = s[:0]（后者防止编译器优化掉nil赋值）
注意：s = s[:0] 只改 len，不释放底层数组；s = nil 才可能让引用计数减一。
为什么预分配容量反而可能延长数组生命周期？
用 make([]int, 0, 1000) 创建一个大容量 slice，即使只存了 3 个元素，底层数组仍是 1000 个 int 的大小。如果这个 slice 被长期持有（比如作为缓存、全局变量、或传入闭包），它背后的整个底层数组就被“锁住”，哪怕逻辑上只需要几个元素。
性能影响：
- GC 压力增大：大数组长期驻留堆上，增加扫描开销
- 内存浪费明显：
len=3, cap=1000的slice实际占用约 8KB（64位），但有效数据仅 24 字节 - 扩容策略不改变这一事实：即使后续
append触发扩容，旧数组是否释放仍取决于是否还有其他slice在引用它
最易被忽略的一点：底层数组的生命周期完全由运行时引用计数决定，和任何单个 slice 变量的作用域结束无关。哪怕你把 slice 变量设为 nil，只要另一个 goroutine 中还存着它的副本，数组就还在。
