确认内存分配黑洞需紧盯HeapInuse是否持续上涨且不回落，而非TotalAlloc；两次/debug/pprof/heap?gc=1快照间隔超30秒，inuse_space净增长超10MB即表明对象被意外“钉住”，非GC未执行。
怎么确认是内存分配黑洞而不是GC没跑完
别看runtime.ReadMemStats里的TotalAlloc，那只是历史总和；真正要盯的是HeapInuse是否持续上涨且不回落。如果两次/debug/pprof/heap?gc=1快照间隔30秒以上，inuse_space净增长超过10MB，基本就是分配后没释放——不是GC失效，是对象被意外“钉住”了。
常见误判点：
- 用
go tool pprof http://localhost:6060/debug/pprof/heap直接看，默认返回的是alloc_objects（所有分配过的东西），不是存活对象 - 没加
?gc=1参数，快照里混着刚分配还没触发GC的垃圾，干扰判断 - 采样间隔太短（
哪些代码模式最容易制造分配黑洞
不是所有make([]byte, n)都危险，但以下写法几乎必踩坑：
-
ioutil.ReadAll或bytes.Buffer.Bytes()返回的切片直接存进全局map或sync.Pool，没做buf[:0]清空，下次Get()拿到的是带旧数据的底层数组 - HTTP handler 里
json.Unmarshal(req.Body, &v)后，把v塞进缓存但没深拷贝，v里含指针字段指向大结构体，整个链路被钉住 - 闭包捕获了含
[]byte字段的局部变量，比如go func(){ use(data) }()，goroutine 没结束，data就一直活在堆上 - 用
strings.Repeat拼接大字符串，底层make([]byte, len)逃逸到堆，且无复用路径
pprof里看到top函数，怎么验证它是不是真凶
别急着重写http.(*conn).serve，先查三件事：
立即学习“go语言免费学习笔记（深入）”；
- 它返回的值有没有被赋给全局变量？比如
cache[reqID] = result却没配TTL或淘汰逻辑 - 它内部是否调用了
io.ReadAll、json.Unmarshal、bytes.Repeat这类“全量加载”操作？尤其注意S3下载、图片解析等IO路径 - 它的参数或局部变量有没有指针类型字段指向大结构体？用
go build -gcflags="-m"看逃逸分析，确认是否本该栈分配却逃逸到了堆
示例：如果top显示encoding/json.(*decodeState).unmarshal占高，实际问题常出在Unmarshal后把结果存进了sync.Map，而Map key是请求ID、value是未清理的struct指针。
sync.Pool没起作用？先检查Put前有没有清空
sync.Pool不是缓存，是对象复用池。它对“高频、短命、无状态”对象才有效，但多数人把它当万能筐往里扔：
-
bufPool.Put(buf)前必须buf = buf[:0]，否则下次Get()拿到的是残留数据，可能引发逻辑错误或隐式内存增长 -
New函数返回了含*http.Request字段的struct，Pool会阻止GC回收整个链路 - 把需要
Close()的资源（如zlib.Reader）扔进Pool，导致fd泄漏，底层堆内存也跟着锁死 - 并发突增时Pool来不及填充，大量fallback到堆分配，反而加剧GC压力
验证方式：用go tool pprof http://localhost:6060/debug/pprof/allocs看该对象的分配次数——如果allocs飙升但inuse_space稳定，说明分配频繁但回收正常；如果两者同步涨，问题大概率在“持有引用”上。
最易被忽略的点：pprof火焰图里看不到的“隐形钉子”，比如一个长期存活的goroutine持有一个channel，而channel接收端一直挂着map引用——heap profile里找不到源头，但goroutine profile里chan receive状态会密集出现。
