go字符串切片不会导致真正内存泄漏，但会因复用底层数组而延长其生命周期；需通过string([]byte(s))显式复制来切断引用。
Go 语言里字符串切片（s[start:end]）不分配新内存，只是复用原字符串底层数组——你留着一个 10 字符的子串，背后可能锁着 10MB 的原始 []byte。这不是 GC 失效，是引用没断。
为什么 s = s[100:105] 后 RSS 不降
字符串底层结构和切片类似：ptr + len，但没有公开 cap。当你从 string(bigBuf) 切出子串，新字符串的 ptr 指向 bigBuf 中间某处，整个底层数组只要还有任意一个字符串或切片引用它，GC 就不能回收。
- 典型场景：HTTP handler 接收大请求体 → 转成
string→ 提取 header 字段（如reqStr[0:12]）→ 把这个短串存进日志结构体或缓存 map - 后果：整个原始请求体底层数组被长期持有着，哪怕 handler 已返回、原始变量已出作用域
- pprof 看到的是大量
inuse_space却找不到“大对象”，因为它们分散在无数小字符串背后
如何真正切断字符串对底层数组的引用
不能靠赋值或截断，必须显式复制数据到新内存。Go 没有 copy(string, string)，但有惯用且高效的两步法：
-
[]byte(s)：这一步强制分配新底层数组，并把子串内容拷过去 -
string(b)：把新字节切片转回字符串，新字符串拥有独立内存
完整写法：safeSub := string([]byte(original[lo:hi]))
注意：original[lo:hi] 本身仍是共享视图，必须套一层 []byte(...) 才触发复制；直接 string(original[lo:hi]) 毫无作用。
结构体字段或 map 值中存子字符串时的隐式陷阱
如果你把子字符串赋给结构体字段或 map value，那个字段/值就成为新的引用持有者，生命周期由宿主决定：
- 错误：
log.Entry{Msg: rawStr[200:210]}—— 整个rawStr底层数组被 log entry 拖住，直到 entry 被 GC - 正确：
log.Entry{Msg: string([]byte(rawStr[200:210]))} - 更安全（避免重复分配）：如果该字段常被重用，可预分配
[]byte缓冲池，但多数场景直接两步法更清晰
尤其要注意全局缓存、中间件上下文、长生命周期 service 实例——它们持有的字符串哪怕只有几个字节，也可能拖垮整个内存水位。
验证是否真释放：别看 RSS，盯 HeapAlloc 和 GC 统计
RSS 高≠泄漏；OS 不还内存是常态。关键指标是 runtime.MemStats.HeapAlloc：
- 在可疑操作前后调用
runtime.ReadMemStats(&ms)，对比ms.HeapAlloc - 若多次操作后
HeapAlloc持续上涨，说明有对象未被回收，大概率是字符串/切片引用未断 - 配合
runtime.GC()（仅调试）+debug.ReadGCStats看NumGC是否递增、LastGC是否更新，确认 GC 真触发了
真正难的不是写对那行 string([]byte(...))，而是意识到哪次 header := body[0:32] 正在悄悄绑架一整块 MB 级缓冲区——它往往藏在一行看似无害的解析逻辑里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
