切片底层数组未释放的典型表现是内存占用不降，因底层数组被其他变量或闭包持有；正确做法是用make+copy创建新底层数组彻底切断引用，而非slice[:0]或nil。
切片底层数组未释放的典型表现
你删了切片元素、甚至 make([]int, 0) 重置，但内存占用没降——不是 GC 慢，是底层数组还被其他变量或闭包持有着。常见于：从大数组里切出小片段传参、缓存中长期保存子切片、结构体字段存了 data[100:105] 这种窄视图。
用 copy + 新底层数组彻底切断引用
只要你不主动复制数据到新底层数组，原数组就一直无法被 GC 回收。关键不是“清空”，而是“换底”。
- 错误做法：
slice = slice[:0]或slice = nil—— 底层数组指针仍在，只是长度变零或指针为空，但若还有别的变量指向同一array，它就活得好好的 - 正确做法：分配新空间，把需要的数据拷过去：
newSlice := make([]int, len(oldSlice)) copy(newSlice, oldSlice)
- 如果只保留前 N 个元素，别用
oldSlice[:N]，改用：newSlice := make([]int, N) copy(newSlice, oldSlice[:N])
结构体内嵌切片时的隐式引用陷阱
结构体字段如果是切片，且你曾用 bigData[lo:hi] 赋值给它，那这个结构体就间接持有了整个 bigData 底层数组。哪怕 bigData 本身已超出作用域，GC 也无法回收。
- 避免直接赋值子切片：
s.Data = bigData[100:105] - 改为显式复制：
s.Data = append([]int(nil), bigData[100:105]...)
或更清晰地用make+copy - 如果结构体生命周期长（比如全局缓存项），务必检查所有切片字段是否来自大源数组
用 runtime/debug.ReadGCStats 验证是否真释放
别靠 pprof 看“大致趋势”，要确认特定操作后底层数组是否真的被回收，得看 GC 统计里堆对象数和下次触发时机的变化。单纯看 RSS 没用，操作系统不会立刻归还内存。
立即学习“go语言免费学习笔记（深入）”；
- 在关键操作前后调用：
var stats runtime.GCStats runtime.ReadGCStats(&stats) fmt.Println(stats.LastGC, stats.NumGC)
- 配合强制触发一次 GC：
runtime.GC()（仅调试用，勿上线） - 重点观察：两次
NumGC差值是否合理、LastGC时间戳是否推进——如果没变化，说明没触发回收，大概率还有活跃引用
make 和 copy，而是意识到哪次赋值悄悄带走了整个底层数组。很多问题直到压测时 RSS 居高不下才暴露，而根源往往藏在某个不起眼的结构体初始化里。 
