inuse_space低但内存爆满是因为alloc_space记录高频临时对象分配，需用allocs分析；debug/pprof注册需import _ "net/http/pprof"且http服务早启动；flat看自身分配，cum看调用链总量。
pprof 内存分析为什么总看到 inuse_space 很低但程序还是爆内存？
因为 inuse_space 只统计 GC 后仍存活的对象，而真正压垮内存的，往往是高频分配又快速释放的临时对象——它们全记在 alloc_space 里，却不会留在 inuse_space 中。
- 直接跑
go tool pprof http://localhost:6060/debug/pprof/heap默认看的是inuse_space，容易误判“没泄漏” - 要查瞬时压力或分配热点，必须显式抓
allocs：go tool pprof http://localhost:6060/debug/pprof/allocs - 如果怀疑是 GC 滞后导致堆积，先手动触发 GC：
curl http://localhost:6060/debug/pprof/heap?debug=1看HeapAlloc和HeapInuse差值；再执行runtime.GC()（或发curl http://localhost:6060/debug/pprof/heap?gc=1）后重采
本地调试时 /debug/pprof/heap 返回 404 怎么办？
不是端口没开，也不是路由写错，而是 net/http/pprof 的注册机制被忽略了——它依赖包级 init 函数自动挂载，但必须确保导入生效且 HTTP server 已启动。
- 必须加这行：
import _ "net/http/pprof"（下划线不能少，否则编译器会优化掉） - HTTP server 要早于主逻辑启动，推荐用 goroutine：
go http.ListenAndServe("localhost:6060", nil) - 已有 HTTP mux（如 gin、echo）？别起新服务，改用：
r.HandleFunc("/debug/pprof/", http.HandlerFunc(pprof.Index)) - 生产环境务必绑定
127.0.0.1:6060，绝不要用0.0.0.0:6060，否则暴露敏感运行时数据
top 命令里 flat 和 cum 到底该信哪个？
flat 是函数自身直接分配的内存，cum 是它及所有下游调用链累计分配的总量。定位“谁申请最多”看 flat；定位“谁触发了高分配链”看 cum。
- 例如
ioutil.ReadAll的flat很高 → 它自己把整个文件读进内存了 - 而
http.(*ServeMux).ServeHTTP的cum很高但flat很低 → 它只是入口，真干活的是下游 handler - 常用组合：
top -cum 10找调用链顶端，再用list 函数名看具体哪行make或append在疯狂扩容 - 注意：默认
top显示的是inuse_space，想看分配量得先切换：top -focus alloc或启动时加-sample_index=alloc_objects
线上服务怎么安全抓一次有效的 heap profile？
线上不能随便停服务、不能让 pprof 接口拖慢响应，更不能把 profile 文件留在磁盘上——得用流式拉取 + 即时分析。
- 用
curl -s "http://$IP:6060/debug/pprof/heap?debug=1" | grep -E "(HeapAlloc|HeapSys|NumGC)"快速看内存水位趋势 - 抓 profile 时加
?gc=1强制 GC 后采集：go tool pprof "http://$IP:6060/debug/pprof/heap?gc=1" - 避免本地保存中间文件，直接管道分析：
curl -s "http://$IP:6060/debug/pprof/heap?gc=1" | go tool pprof - - 火焰图需 graphviz，但线上通常没装；退而求其次用
weblist查源码行：(pprof) weblist main.handleUpload
最常被忽略的一点：pprof 抓的是采样快照，不是实时内存镜像。如果问题只在某次大请求后短暂出现，得配合 GODEBUG=gctrace=1 观察 GC 日志里的 HeapAlloc 跳变，再反向定位时间窗口去抓 profile。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
