slice子切片会“钉住”整个底层数组不被GC回收，因SliceHeader中Data指针仍指向原数组；典型场景包括从大byte切片提取小段存入context或缓存；安全做法是用append([]T{}, s[i:j]...)或make+copy显式复制。
slice 子切片会“钉住”整个底层数组不被 GC 回收
只要任意一个子切片还活着，哪怕只取了前 10 字节，Go 的垃圾回收器（GC）就不会释放它背后那块可能高达几 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) 和你实际要追加的元素数量。
排查时盯死 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]。
