先记住这个答案
在Go中，切片是引用底层数组的窗口。当从一个大的切片创建子切片时，子切片和原切片共享同一个底层数组。即使原切片不再使用，只要子切片存在，GC就认为该底层数组仍被引用，无法释放。为避免内存泄漏，可以使用copy将子切片的内容复制到新的底层数组，或用append([]T(nil), sub...)强制分配新数组，使原数组得以回收。
- 子切片共享底层数组，原数组无法回收
- 使用copy或append到新切片截断引用
- 长生命周期子切片需警惕大数组内存占用
子切片如何锁住底层数组
Go的切片本身不存储数据，它只是底层数组的一个视图。切片头包含指向数组某个元素的指针、长度(len)和容量(cap)。当你使用bigSlice[100:200]得到子切片时，子切片的指针指向索引100，但容量(cap)实际上是原数组从100到末尾的长度，即子切片仍然引用整个底层数组。只要子切片存活，GC就会认为底层数组仍在使用，即使原切片bigSlice已经不再被引用，数组的内存也不会被释放。
举例来说，假设你加载了一个100MB的文件数据到data切片，然后从中截取前1KB的头部放到header。如果后续只保留header，其他数据不再需要，但由于header的cap指向原数组末尾，GC无法回收那约99.9MB的内存。关键在于，切片头中的cap决定了数组的可访问范围，而GC的标记可达性基于切片头引用的数组整体，并非仅当前len部分。
大文件解析头部的内存陷阱
场景：在一个HTTP服务中，每个请求读取一个不超过100MB的缓冲文件，需要解析前256字节的PNG签名。代码简单取子切片header := buf[:256]，之后buf被丢弃，但处理请求的goroutine可能长存，header被传入其他函数。运行一段时间后，内存占用直线上升，OOM频发。因为每个请求的header都持有整个100MB底层数组。
解决：只复制需要的部分，使用header := make([]byte, 256); copy(header, buf[:256])。这样新切片有独立的底层数组，原数组引用消失后立即回收，预期内存占用将显著下降。注意，当原数据后续可能扩展时，可考虑使用append([]byte(nil), buf[:256]...)，效果等价。
截断的适用条件与代价
截断并非所有情况都需要。如果原切片和子切片生命周期相同，或原数组本身较小，截断反而增加一次复制成本。只有子切片引用长期存在且原数组较大、原切片不再使用时才值得。另一个容易忽略的点是，reslice后子切片的cap可能远大于len，这本身不会导致泄漏，但若后续对子切片执行append，可能覆盖原数组的其他元素，引发意外。
代价：copy或append会分配新数组，增加一次内存分配和数据复制，时间上O(n)（n为截取长度）。在极高性能要求时，可改用io.NewSectionReader等流式处理，避免一次性载入。另外，如果原切片只是暂时不用，可能仍会再次引用，截断后无法共享修改，需权衡。
容易答错的地方
- 认为GC基于len释放内存
- 错误认为GC只看到len部分，实际上切片头引用的底层数组长度由其cap决定，GC标记整个数组可达，只要子切片存在，大数组不放。正确做法是主动切断引用。
- 用cap调整截断
- 有人试图用
sub[:cap(sub)]调整，但那样仅改变长度，仍是同一数组。或者认为sub = sub[:256]缩小cap可行，但cap由原数组决定无法缩小。必须复制到新数组。
面试官还会怎么问？
子切片的append操作如何影响内存？
当append不超过cap时，会修改底层数组，可能覆盖原切片数据；超过cap时分配新数组。若子切片cap从原数组继承，append可能意外修改原数组邻近数据，需预先限制cap。
如何判断是否需要截断？
检查子切片是否存活时间远超原切片，且底层数组大小远大于子切片len。若sub的cap/len的比例悬殊且sub长期持有，就应截断。可用len(sub)和cap(sub)调试。
copy截断后还能共享原数据吗？
不能。截断后是新数组，修改新切片不影响原数据。若需要只读共享，可使用只读封装并接受内存不释放，或改用指针+引用计数方案。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。