Go 语言中 slice 底层数组共享导致的内存隐患

先说几个核心判断：slice子切片导致的内存泄漏，在Go项目里其实比想象中更常见。不是因为代码写错了，而是slice的设计本身就带这个“副作用”——只要子切片还在，背后的整块底层数组就别想被GC回收。

slice 子切片会“钉住”整个底层数组不被 GC 回收

只要任意一个子切片还存活着，哪怕只取了前10个字节，Go的垃圾回收器就不会释放它背后那块可能高达几MB的原始底层数组。这不是bug，是slice设计的必然结果——slice本质上是SliceHeader{Data uintptr, Len int, Cap int}，Data指针一旦挂上，整块内存就被“钉死”了。

哪些场景容易中招？

• http.Request.Body读出的[]byte，然后做body[8:16]提取trace ID，存进context.WithValue——这是典型高危操作
• 数据库rows.Scan(&data)后对data取data[100:120]，再塞进全局缓存
• strings.Split()返回的[]string，每个string底层仍指向原始大字符串的数组

这些操作的共同点：从一个大块内存上借了一小段，却让整块内存都“活着”。

用append([]T{}, s)或copy显式切断引用

想安全提取一小段数据又不拖累内存，必须自己动手分配一个新底层数组。两种主流做法：

• safe := append([]Passenger{}, passengers[0:3]...) —— 写法简洁，但每次调用都会触发一次小分配（内部等价于make+copy）
• safe := make([]Passenger, 3); copy(safe, passengers[0:3]) —— 容量控制明确，无额外开销，性能敏感路径推荐用这个
• Go 1.20+可直接用bytes.Clone()（仅限[]byte），语义最清晰

千万别用s[0:len(s)]或s[:]来“重置”，那只是调整len和cap，Data指针纹丝不动。这种操作解决不了内存泄漏问题。

扩容时的“断连”不是保险箱

append是否共享底层数组，只取决于当前cap是否足够。举个例子：

original := []int{1,2,3}
s1 := original
s2 := append(s1, 4) // cap(original)==3 → 触发扩容 → s2.Data ≠ s1.Data

但如果original是make([]int, 3, 8)，同样的append(s1, 4)就仍在原数组上操作，s1[0] = 99会立刻反映在s2上。

所以，不能靠“append过没”来判断是否安全。唯一可靠依据是：cap(s)和你实际要追加的元素数量。这一点很容易被忽视，但恰恰是很多隐蔽bug的根源。

排查时盯死pprof heap profile中的[]uint8分配峰值

内存泄漏往往藏在看似无害的子切片里。用go tool pprof -http=:8080 ./binary http://localhost:6060/debug/pprof/heap查看堆分配热点，重点观察：

• 有没有长期存活、flat占比异常高的[]uint8实例
• 点击展开后，调用栈是否指向io.ReadAll、json.Unmarshal、database/sql.Rows.Scan等常见入口
• 顺着栈往上找，看哪行代码做了s[i:j]并把结果传给了长生命周期对象（如struct字段、map、channel）

真正危险的从来不是大slice本身，而是那个只取了16字节却让1MB内存永远无法释放的s[0:16]。记住一句话：借了就要还，不还就别借。