底层数组的生命周期由运行时引用计数决定，与单个slice变量作用域无关；只有当所有持有其array指针的slice均不可达且引用计数归零时，GC才回收该数组。
底层数组不会随 slice 变量消失而释放
Go 中底层数组的生命周期和任意单个 slice 变量的作用域结束完全无关。哪怕你在函数末尾写了 s = nil，只要还有另一个 goroutine 持有该 slice 的副本、或某个闭包捕获了它、甚至只是被传给了 json.Marshal 这类接受 interface{} 的函数（内部可能保留了 &s[0]），那块底层数组就还在堆上。
常见错误现象：
- 从一个大
[]byte切出 10 字节的子切片后丢弃原 slice，结果整个 MB 级底层数组被“钉住” - 函数返回
s[10:11]，调用方长期持有该返回值 → 入参背后的大数组无法回收 - 把
make([]int, 0, 10000)放进 map 或全局缓存，即使只写入 3 个元素，80KB 底层数组也一直驻留
如何主动切断对底层数组的引用
想让底层数组尽快被 GC 回收，核心是确保没有任何 slice header 还持有它的 array 指针。仅靠 s = nil 不够，因为编译器可能优化掉赋值；仅用 s = s[:0] 更不行——它只改 len，cap 和 ptr 都没变。
可靠做法：
立即学习“go语言免费学习笔记（深入）”；
-
newS := make([]T, len(oldS)); copy(newS, oldS)：分配新底层数组，彻底分离 -
newS := append([]T(nil), oldS...)：利用nil切片 cap 为 0 的特性，强制走新分配路径 -
s = nil; s = s[:0]：先置 nil 再截断，防止编译器优化，确保引用计数减一
make 时容量参数为变量必然导致逃逸
make([]byte, 0, n) 中的 n 如果是运行时变量（比如从 HTTP 请求解析出的 limit），底层数组一定分配在堆上。编译器不看实际用了多少元素，只看容量能否静态推断。
验证方式：go build -gcflags="-m -l" 输出中出现 escapes to heap 即表示逃逸。
可选修复：
- 若
n有合理上限，改用常量容量，如make([]byte, 0, 4096) - 预分配并复用底层数组，避免高频
make - 对含指针元素的切片（如
[]*User），哪怕容量是常量也几乎必然逃逸，此时考虑改用值类型[]User并按需取地址
[]T 与 []*T 的内存布局差异直接影响生命周期
[]T 的底层数组直接存结构体实例，T 实例的生命周期由切片整体绑定；[]*T 的底层数组只存指针，T 实例可能分散在堆各处，各自独立存活。
这意味着：
- 一个
[]User被 GC，其所有User实例也一同不可达；但一个[]*User被回收，只释放指针数组（8字节 × length），User实例是否存活取决于其他引用 -
[]*T更易造成内存碎片，且访问需额外解引用，但传递成本低；[]T内存紧凑、访问快，但复制大结构体时拷贝开销明显
真正容易被忽略的是：底层数组的销毁时机，永远取决于所有持有其 array 指针的 slice 是否全部不可达 —— 不是看谁定义了它，而是看谁还“攥着”它。
