不能。runtime/debug.ReadGCStats仅记录GC周期统计（如暂停时间、次数），不反映堆上对象分布或存活状态，无法检测大字符串泄漏；应使用runtime.ReadMemStats配合pprof分析HeapInuse、HeapAlloc等指标，并结合debug.SetMemoryLimit设硬限防OOM。
runtime/debug.ReadGCStats 能不能抓到大字符串泄漏
不能。它只记录 GC 周期统计（如 pause 时间、次数），不反映堆上对象分布或存活状态。大字符串（比如 string 底层数组）是否泄漏，得看它是否被长期引用——runtime/debug.ReadGCStats 完全不提供这个视角。
真正该用的是 runtime.ReadMemStats 配合 pprof：
- MemStats.HeapInuse 持续上涨 → 存活对象在涨
- MemStats.HeapAlloc 和 MemStats.HeapSys 差值大 → 有大量未归还的堆外内存（比如大 string 被 unsafe.String 或 cgo 持有）
- MemStats.HeapObjects 线性增长且不回落 → 典型泄漏信号
为什么 string 会成内存溢出主因
Go 中 string 是只读头 + 底层数组指针，复制或拼接（+=、fmt.Sprintf）都会触发底层数组拷贝。一个 100MB 的日志片段转成 string，就占 100MB 连续堆内存；若被闭包、map 或 channel 缓冲区意外持有，GC 就永远清不掉。
常见踩坑点：
- 用 strings.Builder.String() 后没清空，Builder 底层数组被复用但长度没重置
- http.Request.Body 读完后直接 string(bodyBytes)，又塞进全局 map[string]string
- 在 goroutine 里循环拼接日志：s += line，每次分配新数组，旧数组残留直到所有引用消失
- 用 unsafe.String 包装 mmap 或 cgo 返回的内存，但忘了手动释放或没配 finalizer
用 debug.SetMemoryLimit 控制 string 分配上限（Go 1.22+）
Go 1.22 引入了 debug.SetMemoryLimit，它是比 GOMEMLIMIT 更底层的硬限：一旦进程 RSS 接近该值，runtime 会主动 panic，而不是等 OOM Killer 杀进程。对 string 泛滥场景特别有用。
实操建议：
- 在 main() 开头尽早调用：debug.SetMemoryLimit(1 <br>
- 它只对 Go 分配器生效，不影响 mmap/cgo 内存，所以必须配合检查 <code>MemStats.HeapSys
- panic 时堆栈会包含最后一次大分配位置，比 dmesg 的 “Killed process” 更精准定位到哪行生成了巨型 string
- 注意：该函数不可逆，且设太低会导致合法请求失败，建议设为容器 memory limit 的 80%
pprof 查大 string 必须加 -alloc_space 和 focus
go tool pprof -inuse_space 只显示当前存活的 string 头（16 字节），根本看不出内存占比；真正要查的是底层数组分配源头。
立即学习“go语言免费学习笔记（深入）”；
正确姿势：
- 启动时加 -memprofilerate=1（测试环境）或 -memprofilerate=1024*1024（线上）
- 用 go tool pprof -alloc_space heap.pb.gz 打开，执行 top 看总分配量
- Web UI 中点击 Focus 输入 runtime.makeslice 或 runtime.string，再点 View → Call graph
- 重点关注调用栈里出现 strings.Repeat、fmt.Sprintf、bufio.Scanner.Bytes 的位置
容易被忽略的一点：如果 pprof 显示大量 runtime.convT2E 或 runtime.convT2I 占内存，往往是因为把大 string 当作 interface{} 塞进了 map 或 channel——接口转换会触发底层数组拷贝。
