Go 小切片为什么会占着大数组不释放

把一段几十 MB 的请求缓冲区裁成几十个字节后放进缓存，进程的堆内存却一直降不下来，这通常不是 GC 失效，而是返回的小切片仍指向原来的大底层数组。Go 的切片只记录指针、长度和容量，buf[:32] 只改变这三个数里的长度和可用范围，并不会复制数据。需要长期保存小片段时，应明确复制一次，让它脱离大数组。

小切片为什么还会让大数组存活

下面这个函数只想保留日志头部：

func header(packet []byte) []byte {
    return packet[:64]
}

如果 packet 来自一个 32 MB 的接收缓冲区，返回值的 len 只有 64，但它的指针仍然落在那块 32 MB 数组中。只要返回值被缓存或被某个长期对象持有，垃圾回收器就不能把包含这 64 个字节的底层数组当成不可达对象。这里“占着不释放”说的是可达性，不是切片变量本身变大了。

可以把一个切片想成“数组起点 + len + cap”的窗口。重新切片只是移动窗口边界，不会自动产生新的存储。官方规范也说明，同一数组产生的切片会共享存储；因此修改共享范围内的元素，可能影响另一个切片。

先分清 len、cap 和 append 的实际边界

排查这类问题时，不要只打印 len(part)。len 是当前可读写的元素数，cap 是从切片起点到原底层数组末端的可扩展范围；两个值都不等于“这次分配了多少字节”。例如：

buf := make([]byte, 32

三下标切片把 limited 的容量限制为 64，能够防止后续 append(limited, ...) 悄悄写进原数组的后续区域；它仍然没有复制数组，所以不能解决长生命周期持有问题。只有当追加内容超过容量时，append 才会分配新的底层数组；容量足够时仍会复用旧数组。

需要长期保存时，复制出紧凑副本

最直白的写法是按有效长度分配新数组，再复制内容：

func cloneHeader(packet []byte) []byte {
    if len(packet) 

如果只处理字节或字符串片段，也可以写成：

header := append([]byte(nil), packet[:64]...)

这两种方式的关键都不是“把 cap 设小”，而是创建一块新的底层数组。复制完成后，缓存里保存的是 64 字节数组；当原始 packet 没有其他引用时，32 MB 缓冲区就有机会被回收。

复制也意味着数据不再与原切片共享。后续修改 header 不会回写 packet，这通常正是缓存、异步消息和跨层返回值需要的隔离语义。

指针元素、缓存字段和验证清单

对于 []byte，核心问题通常是底层数组本身过大。对于 []*Item 或带指针字段的结构体切片，还要注意“不可见但仍存于底层数组中的元素引用”。如果是在同一个数组里做删除或压缩，旧槽位可能继续保留指针，使对象仍然可达；此时应在缩短切片前把不再使用的槽位清零，或直接复制到一个新切片。

items = append(items[:i], items[i+1:]...)
var zero *Item
items[len(items)-1] = zero // 清掉尾部隐藏引用
items = items[:len(items)-1]

最后用检查清单确认修复方向：

• 这个切片是否会进入全局缓存、结构体字段、闭包、channel 或后台 goroutine？
• 它是否只是 big[:n] 得到的窗口，还是已经通过 copy 获得独立存储？
• 元素类型是否包含指针，旧数组里是否还有不可见的对象引用？
• 是否观察了堆对象趋势，而不是把一次 GC 后的常驻内存误认为泄漏？

常见问题

把切片设为 nil 就能释放大数组吗？

只有当没有其他切片、数组指针或对象继续引用它时才有机会释放。把一个局部变量设为 nil，不能消除缓存字段里的同一底层数组引用。

三下标切片能替代复制吗？

不能。s[:n:n] 只限制容量，仍然共享原数组；它适合防止追加越界式地复用后续空间，不适合切断大数组的生命周期。

复制每个小切片会不会反而变慢？

会增加一次分配和复制成本，所以短期计算路径不必机械复制。若小片段会存活很久、原缓冲区很大，复制成本通常换来了更低的长期堆占用，应结合缓存命中周期和内存曲线决定。

判断标准可以压缩成一句话：短暂使用就共享，长期保存就复制；需要限制追加范围时再使用三下标切片。只看 len 或把 cap 调小，都不能替代真正的数据迁移。