核心是定位持续分配、未释放和卡住不走的对象；90%因生命周期管理失控，如http.client未复用、sync.pool泄漏大对象、全局map缓存未清理元数据；须用-alloc_space而非默认heap采样，重点关注top中encoding/json.(*encodestate).marshal等高频分配源。
pprof 图形化分析 Go 长连接内存增高，核心不是看火焰图“谁颜色深”，而是要定位“谁在持续分配、谁没释放、谁卡住不走”。长连接服务内存缓慢上涨，90% 与连接本身无关，而是生命周期管理失控——比如 http.Client 没复用、sync.Pool 缓存了大对象、或全局 map 不断塞入未清理的连接元数据。
为什么火焰图里全是 runtime.mallocgc 和 runtime.systemstack
这是采样失焦的典型信号：runtime.mallocgc 只说明“有分配发生”，不代表它是罪魁祸首；runtime.systemstack 占比高往往只是 goroutine 切换频繁的副产品。真正该盯的是这些分配的**调用者**：
-
net/http.(*Transport).RoundTrip频繁出现 → 检查http.Transport的MaxIdleConns和MaxIdleConnsPerHost是否为 0 或过小，导致每次请求都新建连接 -
grpc.newClientTransport反复调用 → 客户端未复用grpc.ClientConn，或连接未设置WithBlock()+ 超时兜底 -
encoding/json.(*encodeState).marshal或bytes.makeSlice排在top前三 → 序列化/反序列化高频触发，且未复用sync.Pool中的bytes.Buffer或json.Encoder
必须用 -alloc_space，而不是默认 heap
/debug/pprof/heap 默认返回的是 -inuse_space（当前存活对象），对长连接服务几乎无效——因为对象可能刚分配、GC 还没扫到，或者被引用链牢牢锁住。真正反映“持续增高”的指标是累计分配量：
- 执行
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap - 进入交互后输
top，重点看前三是否含strings.Builder.Write、bufio.NewReader、net/http.(*persistConn).readLoop - 若
net/http.(*persistConn).readLoop占比高，说明大量连接卡在读响应上——本质是连接没关闭，其持有的bufio.Reader和bytes.Buffer持续占堆 -
sync.Pool的New函数创建的大对象不会出现在heapprofile，但会推高-alloc_space，需单独检查 Pool 初始化逻辑
两次采集对比？别信 /heap?gc=1 立即采
长连接服务内存增长缓慢，强制 GC 后立刻抓 /heap?gc=1 得到的 InuseSpace 常接近零——对象还没被标记为可回收，或清扫阶段尚未触发。这种对比毫无意义。
- 正确做法：确保有真实流量（建连/断连/发请求），等至少 60 秒以上再采第二次
- 对比关键指标是
AllocSpace（累计分配）而非InuseSpace：若 2 分钟内AllocSpace上涨 50MB 且无对应业务释放动作，基本可定性为泄漏 - 更准的辅助手段：访问
/debug/pprof/goroutine?debug=2，确认是否有大量net/http.(*persistConn).readLoop或io.ReadFull状态为select或chan receive的 goroutine 长期存活
图形化火焰图里“扁平但单次开销大”的操作容易被忽略
长连接中，低频但高开销的操作（如首次 TLS 握手、证书验证、JWT 解析）在火焰图里常表现为窄而浅的分支，颜色不深，但 list 查具体函数会发现单次分配几 MB 的切片或 map。
- 不要只依赖
web命令生成的 SVG，一定要进交互模式输list 函数名看实际分配行号 - 特别关注
crypto/tls.(*Conn).Handshake、golang.org/x/oauth2/jwt.(*Config).TokenSource等初始化类函数 - 若用
context.WithTimeout包裹连接建立，但超时后未显式Close()底层 conn，TLS 握手残留结构体仍会驻留堆中
