Go 切片截取后，为什么大数组迟迟无法释放？

接口只返回前 100 条记录，进程内存却一直很高；日志解析只保留几 KB 头部信息，几十 MiB 的缓冲区却迟迟不降。这类问题经常被误判为 GC 不够积极，实际根因通常是：小切片仍然引用着大数组。

Go 的切片不是数组本身。它更像一个窗口，记录了底层数组的位置、长度和容量。截取切片时，窗口变小了，但窗口背后的数组并不会自动复制。

切片只是数组的窗口

可以把切片理解成一个描述符：它包含指向底层数组的指针、当前长度和容量。指针决定了切片从哪里开始，长度决定了能访问多少元素，容量决定了从当前位置继续追加时还有多少空间。

下面这段代码只截取了 10 个字节：

big := make([]byte, 100<<20)
small := big[:10]
fmt.Println(len(small), cap(small))

small 的长度是 10，但它仍然指向 big 背后的 100 MiB 底层数组。只要 small 还活着，GC 就必须认为这块大数组仍然可达。

GC 为什么不能回收

GC 只关心对象是否可达，不理解业务上“只需要前 10 个字节”。如果一个小切片指向大数组中的某个位置，大数组就仍然在引用链上。

下面的函数很容易在业务代码中出现：

func readPrefix() []byte {
    data := make([]byte, 100<<20)
    // 省略：读取文件或网络响应
    return data[:1024]
}

调用方拿到的返回值只有 1 KiB，但这 1 KiB 仍然引用 100 MiB 底层数组。如果它被放入缓存、结构体字段或异步任务闭包，大数组就会跟着一起长期驻留。

这不是传统意义上的内存泄漏，而是“仍然可达但业务上不再需要”的内存保留问题。GC 行为是正确的，代码的引用关系才是关键。

用复制切断引用

如果截取结果要长期保存，就应该复制出一份新的小切片。最常见的写法是 append：

func readPrefix() []byte {
    data := make([]byte, 100<<20)
    prefix := data[:1024]
    return append([]byte(nil), prefix...)
}

append([]byte(nil), prefix...) 会分配新的底层数组，并把 prefix 的内容复制进去。返回值只持有约 1 KiB 的新数组，原来的 100 MiB 数组在没有其他引用后即可被回收。

标准库也提供了更直观的 slices.Clone：

func readPrefix() []byte {
    data := make([]byte, 100<<20)
    return slices.Clone(data[:1024])
}

slices.Clone 的语义就是复制切片。对于函数返回值、缓存值、跨 goroutine 传递的数据，它比裸截取更能表达意图。

三索引切片不是释放方案

Go 支持三索引切片，可以限制新切片的容量：

big := make([]byte, 100<<20)
small := big[:1024:1024]
fmt.Println(len(small), cap(small))

这里 small 的长度和容量都是 1024。好处是后续对 small 执行 append 时，容量不足会触发新分配，避免继续写入原来的大数组。

但三索引切片仍然指向原底层数组：

big := make([]byte, 100<<20)
small := big[:1024:1024]
runtime.KeepAlive(small)

所以它只能控制追加行为，不能单独解决大数组释放问题。只要 small 还活着，旧数组就仍然可达。真正要切断引用，仍然需要复制。

什么时候必须复制

不是所有切片截取都需要复制。函数内部临时读取、临时校验、临时解析，一般可以直接截取。只要小切片不会逃出当前生命周期，大数组自然会在不可达后被回收。

更应该复制的场景包括：小切片会作为函数返回值；会进入缓存、队列或全局状态；会保存到结构体字段；原始缓冲区来自大文件、网络响应或对象池；从几十 MiB 中只保留几 KB。

判断原则很简单：截取结果是否比原始数据活得更久。如果答案是肯定的，并且原始数据明显更大，就应该复制。

如何排查

线上排查时，不要只看 GC 次数。切片引用底层数组属于可达对象问题，GC 再频繁也不会释放仍被引用的数据。

可以先用 go tool pprof http://localhost:6060/debug/pprof/heap 查看堆画像。

如果堆中长期存在大块 []byte，需要沿引用链查找是谁持有了小切片。常见位置包括缓存 map、解析结果结构体、消息队列、日志上下文字段和异步任务闭包。

修复后，再通过压测或复现脚本观察堆占用是否回落。若复制后内存明显下降，基本可以确认问题来自底层数组被意外保留。

写在最后

Go 切片截取后大数组迟迟无法释放，并不是 GC 失效，而是小切片让底层数组保持可达。切片共享底层数组带来了高效截取，也带来了隐藏的内存保留风险。

生产代码可以记住三条规则：短期使用可以直接截取；长期保存小片段时需要复制；三索引切片只能限制容量，不能替代复制。理解这三点，很多“内存怎么降不下来”的问题都会变得清晰。