Go字符串截取不释放大内存是因为共享底层数组，string(s[start:end])仅调整指针和长度而不复制数据，导致子串存活时原始大数组无法被GC回收；解决方法是用string([]byte(sub))强制创建独立副本。
字符串截取后大内存不释放，是因为共享底层数组
Go 的 string 是只读的 header + 底层数组指针，s[start:end] 不复制数据，只是调整指针偏移和长度。所以哪怕你只取 10 字节，只要这个子串还活着，整个原始百万字节的底层数组就卡在内存里——GC 看到还有引用，不敢动。
典型现象：压测时 RSS 持续上涨、pprof 显示大量 []byte 占用堆，但代码里早把原始字符串置为 "" 或出了作用域。
- 常见于：解析大 JSON/protobuf 后只提取几个字段；日志中截取 traceID；HTTP body 中提取 token
- 注意：这不是 bug，是 Go 的设计取舍——性能优先，但你要为内存负责
用 string([]byte) 强制创建独立副本
最直接、零依赖的解法：先把子串转成 []byte，再转回 string。这会触发一次内存分配和拷贝，切断与原数组的联系。
示例：
立即学习“go语言免费学习笔记（深入）”；
// 原始大字符串（比如读取的整个文件）
large := strings.Repeat("x", 10_000_000) // 10MB
sub := large[100:105] // "xxxxx"，但底层数组仍是 10MB
// ✅ 正确：强制分离
independent := string([]byte(sub))
// ❌ 错误：什么都没断开
// independent = sub // 仍共享底层数组
-
[]byte(sub)会分配新底层数组并拷贝内容，string(...)再基于它构造新字符串 - 性能代价可控：仅对真正需要隔离的小片段做，不是所有字符串都这么干
- 别用
fmt.Sprintf("%s", sub)—— 它底层可能复用原数组，行为不确定
结构体字段存子字符串时，隐式持有整个底层数组
如果把截取后的子串赋给结构体字段（尤其是长生命周期对象），那个结构体就间接持有了原始大数组的全部内存。
示例：
立即学习“go语言免费学习笔记（深入）”；
type Request struct {
TraceID string
}
// ❌ 危险：traceID 共享了整个 body 底层数组
req := &Request{TraceID: body[20:40]}
// ✅ 安全：显式复制
req := &Request{TraceID: string([]byte(body[20:40]))}
- 全局缓存、连接池、中间件上下文里的字符串字段，都要检查是否来自大源
- 尤其警惕
http.Request.Body、bufio.Scanner.Bytes()返回的[]byte转成的string - 用
unsafe.Sizeof或 pprof 查看结构体实际内存占用，常比预期大几个数量级
验证是否真切断了引用
光写对代码不够，得确认 GC 真把它回收了。别信 RSS，要看堆对象统计。
关键操作前后加：
var stats runtime.MemStats
runtime.GC() // 强制一次（仅调试）
runtime.ReadMemStats(&stats)
log.Printf("HeapObjects: %d, HeapAlloc: %v", stats.HeapObjects, stats.HeapAlloc)
- 对比两次调用间
HeapObjects是否下降，HeapAlloc是否回落 - 若没变化，说明还有活跃引用——回去查结构体、闭包、map value、goroutine 参数
- 线上禁用
runtime.GC()，改用持续采样 + pprof heap profile 对比
真正难的不是写那行 string([]byte(s))，而是意识到某个 req.ID = raw[8:16] 正在悄悄拖住 50MB 内存。这种引用链往往跨函数、跨 goroutine，直到 OOM 才暴露。
