拐点必须通过两次heap采样diff分析定位，而非单次火焰图；火焰图无时间维度，仅显示当前内存占用，无法反映增长过程。
单次 heap 火焰图根本看不到拐点——拐点是两个时间点之间的差值，不是快照里的颜色深浅。
为什么 web 火焰图里找不到突增拐点
火焰图只渲染单个 heap profile 快照，它没有时间维度。你看到的是“此刻谁占着内存”，不是“谁在什么时候突然多占了内存”。长连接服务中，对象可能存活数分钟甚至数小时，突增往往由某次批量操作（如推送 1000 条消息）触发，但这个动作在单张火焰图里会被稀释、淹没，或压根不显眼。
-
go tool pprof -http=:8080 heap.prof只能展示当前 in-use 对象分布，无法体现增长过程 - 如果突增后 GC 尚未完成清扫，
?gc=1采样反而会漏掉刚分配但未标记为可回收的对象 - 火焰图顶部常堆着
runtime.mallocgc和runtime.systemstack，这只是分配入口，不是业务源头
必须做两次采样并 diff，且参数不能错
真正定位拐点的操作链是：内存正常时采 baseline → 触发疑似突增行为 → 立即再采 second → 用 -base 做差分。关键不在“画图”，而在“比对”。
- 第一次采集：
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" -o heap-before.prof - 第二次采集前，手动触发业务动作（例如调用
/memory-leak-demo或推送一批数据），再立刻执行：curl -s "http://localhost:6060/debug/pprof/heap?gc=1" -o heap-after.prof - diff 命令必须带二进制文件（否则函数名是地址）：
go tool pprof -base heap-before.prof myapp binary heap-after.prof - 进入交互后，优先用
top -cum -inuse_space查当前存活对象的累计占用差异；若增长缓慢，改用top -cum -alloc_space看分配量新增
图形化只是放大器，不是探测器
生成火焰图本身不解决拐点问题，但它能把 diff 后的差异路径可视化放大。前提是 diff 已定位到可疑函数，否则图形再炫也没用。
- diff 后发现
encoding/json.(*encodeState).marshal在-alloc_space模式下排第一？说明突增来自某次序列化逻辑，不是连接本身 - 如果
net/http.(*persistConn).readLoop在-inuse_space中占比高，实际问题是连接没关，导致其持有的bufio.Reader长期驻留 - 图形中节点字体大 ≠ 该函数写得差，而是它调用链下游持续分配；重点看 cum 值大的叶子节点，比如
bytes.makeSlice或strings.Builder.grow - 生产环境慎用
web命令自动生成 SVG——它默认依赖 graphviz，而很多容器镜像没装；可用peek或list快速聚焦函数源码行
拐点分析最易被忽略的一点：你对比的不是“有没有涨”，而是“谁涨得最多、在什么路径上、是否与连接数线性相关”。inuse_space 差值随连接数翻倍，alloc_space 差值集中在某次 handler 调用里——这两个信号交叉验证，才能锁定真实拐点。
