切片截取 s[i:j] 不会释放原底层数组，只要子切片存活，整个底层数组就被 gc 钉住；因其仅更新 sliceheader 中 data、len、cap 三字段，不分配新内存，但 cap 保留原数组剩余空间，导致内存滞留。
直接说结论：切片截取 s[i:j] 不会释放原底层数组，只要截取后的切片还活着，整个原始数组就一直被 GC 锁住——这不是 bug，是设计使然，但极易引发内存泄漏。
为什么 s[i:j] 后内存不降？
Go 切片本质是“视图”，s[i:j] 只改了头里的指针偏移和长度，底层数组地址、容量全都没变。pprof 里看到一堆 []byte 占着几 MB 堆内存，但你的业务逻辑只用了其中几十字节，大概率就是这个原因。
常见错误现象：
- 服务运行几小时后 RSS 持续上涨，
runtime.GC()后无明显回落 - 用
pprof.Lookup("heap").WriteTo(w, 1)查看，高占比类型是[]byte或[]string，且实例大小远超你“以为”持有的数据量 - 从大文件读取
[]byte后只取 header 部分存进 map，结果整个文件内容长期驻留
怎么安全地截取并切断引用？
核心原则：需要副本时，必须显式分配新底层数组；不是靠“看起来新建了切片”来解决。
- 对
[]byte（最常见场景）：优先用bytes.Clone()（Go 1.20+），语义明确、零额外开销；旧版本用append([]byte{}, s[i:j]...)或copy(dst, s[i:j]) - 对泛型切片
[]T：写法更稳妥的是newSlice := make([]T, len(s[i:j])); copy(newSlice, s[i:j]) - 别信
make([]T, 0, cap)能防泄漏——它造的是全新数组，跟你截取的s[i:j]完全无关，属于典型误用 - 三索引
s[i:j:k]也不能切断引用，它只限制后续append行为，cap(s[i:j:k])仍是cap(s) - i，只要i小，底层数组就大概率还在被强引用
重切（如 s = s[1:]）时为什么还要手动置零？
重切只是挪动切片头，底层数组那些“已被切掉”的槽位依然存在，如果里面存的是指针、map、interface{} 或大 string，GC 会认为这些对象仍可达。
- 指针类型（
*T）：切前设s[0] = nil -
string类型：设s[0] = ""（注意不是局部变量赋空） -
[]byte类型：设s[0] = nil - 接口或 map：统一用
s[i] = nil - 漏掉这步，哪怕你只弹出一个
*big.Struct，它背后几 MB 的数据也永远收不回来
字符串截取也有同样问题
字符串不可变，但 str[i:j] 共享原字符串底层 []byte。一个 10MB 的日志字符串，截出 "ERROR" 存进缓存，整个 10MB 就卡在内存里。
- 必须创建真正独立副本：
substr := string([]byte(original[i:j])) - 不要用
unsafe.String或反射绕过——那只是把问题藏得更深 - 若频繁做这类操作，考虑在读取源头就按需解析，而非先全读再截取
真正难处理的从来不是“怎么写”，而是“什么时候该怀疑是切片引用导致的泄漏”——一旦发现某段逻辑长期持有小切片、又伴随内存缓慢上涨，先查 pprof 看 heap profile 里大块 []byte 的调用栈，八成就是它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
