结论：切片截取 s[i:j] 不会触发底层数组释放，只要该切片或任何持有其头信息的变量还存活，整个原底层数组就无法被 GC 回收——哪怕只取 2 个字节，背后可能扛着几 MB 内存；因其仅更新 ptr、len 和 cap，不复制数据，底层数组地址与大小均不变。
直接说结论：切片截取 s[i:j] 不会触发底层数组释放，只要该切片或任何持有其头信息的变量还存活，整个原底层数组就无法被 GC 回收——哪怕你只取了 2 个字节，背后可能扛着几 MB 的内存。
为什么 s[i:j] 后内存不降？
Go 的切片不是数据副本，只是一个三元组：ptr（指向底层数组某位置）、len、cap。执行 s[i:j] 时，Go 只更新 ptr 和 len，cap 变为 cap(s) - i，但底层数组地址没变、大小没变、所有元素仍在内存中。
常见错误现象：
-
runtime.ReadMemStats显示HeapInuse持续上涨，GC后不回落 - pprof heap profile 里
[]byte占比异常高，且多数来自大文件读取后只取 header 的场景 - 长期运行的服务 RSS 内存稳步上升，重启后归零
哪些场景必须手动切断引用？
不是所有截取都危险，关键看“被切掉的部分是否含可回收资源”：
立即学习“go语言免费学习笔记（深入）”；
- 元素类型是
*T、map[K]V、chan T、func()或含指针字段的 struct：必须置零再截取，否则指针仍可达 - 元素是
string：字符串头含指向底层[]byte的指针，s[0] = ""才能清空该槽位引用 - 元素是纯值类型（如
int、bool）且不含嵌套指针：通常不用置零，但若底层数组本身巨大（如百万级[]int），仍建议复制隔离
怎么安全地截取并释放？
别依赖“看起来新建了切片”，要确保新切片拥有独立底层数组：
- 对任意类型通用：先
make([]T, len(s[i:j]))，再copy(newSlice, s[i:j]) - 对
[]byte（Go 1.20+）：直接用bytes.Clone(s[i:j])，语义明确、零额外分配 - 对小 slice 且需兼容旧版本：用
append([]T{}, s[i:j]...)，强制触发新底层数组分配 - 避免误用：
make([]T, 0, cap)创建的是全新数组，和原 slice 完全无关——它根本没解决截取后的引用问题
三索引切片 s[i:j:k] 能防泄漏吗？
不能。它只限制后续 append 的最大容量，不影响当前底层数组绑定关系。cap(s[i:j:k]) == k-i，但 cap(s) 仍决定原始底层数组总长。只要 i 很小，底层数组大概率还在被引用。
真正容易被忽略的点是：泄漏往往不出现在截取那一刻，而在于你把 s[i:j] 存进了 long-lived 结构（比如全局 map、缓存池、channel 发送端），导致整个底层数组被意外锚定。查泄漏时，得顺着引用链反向追踪，而不是只盯着截取那一行代码。
