真泄漏需满足heapinuse在稳定负载下线性增长且重启复现；查泄漏应盯inuse_space差值而非allocs，因前者反映长期存活对象，后者仅表分配频次；须用?gc=1强制gc后采样两次对比，再结合goroutine栈定位“钉住”对象的持有者。
Go 程序内存持续上涨，90% 不是“没释放”，而是高频分配 + GC 来不及回收，或对象逃逸到堆上反复 new；pprof 的 /debug/pprof/heap 默认不显示泄漏，?alloc_space 才是查源头的关键。
为什么 heap profile 显示内存很低，但 RSS 却一直涨
默认访问 /debug/pprof/heap 返回的是「当前存活对象」（InuseSpace），GC 后很多短期对象已被回收，所以数值偏低。而 RSS 涨是操作系统视角的物理内存占用，它包含已分配但尚未被 GC 归还给系统的页 —— 这类内存不会立刻出现在 InuseSpace 里。
- 真正要定位分配源头，必须用
/debug/pprof/heap?alloc_space=1，它统计所有 malloc 累计字节数 - 配合
go tool pprof -alloc_space heap_alloc.pprof，再输入top，才能看到strings.Builder.Write或encoding/json.(*encodeState).marshal这类高频分配点 - 若
runtime.mallocgc排第一但业务函数没上榜，大概率是字符串拼接、JSON 序列化、日志格式化这类反射-heavy 操作在底层疯狂 new 对象
确认是否真的内存泄漏：必须做两次对比采样
单次 heap 快照毫无意义。泄漏的本质是「对象长期存活且数量/大小随请求线性增长」，必须靠差值判断。
- 第一步：请求
/debug/pprof/heap?gc=1（强制 GC 后采），记下InuseSpace值 - 第二步：等 30–60 秒（期间触发几轮业务请求），再请求同地址，观察
InuseSpace是否明显上升 - 第三步：如果持续上涨，且没有对应业务逻辑显式释放资源（如关闭
*sql.Rows、未调用sync.Pool.Put），基本可定性为泄漏 - 注意：
sync.Pool缓存的对象不会出现在 heap profile 里，但若New函数本身创建大对象（如bytes.Buffer底层预分配 4KB），仍会推高AllocSpace
火焰图里全是 runtime.xxx？你缺了原始二进制文件
pprof 分析时若看不到自己的函数名，只显示 runtime.mallocgc 或一堆十六进制地址，不是代码问题，是分析环节漏了关键依赖。
-
go tool pprof必须传入部署时使用的原始可执行文件（即你go build生成的二进制），否则无法解析符号表 - 错误用法：
go tool pprof cpu.pprof→ 只有 profile 数据，无符号信息 - 正确用法：
go tool pprof myservice cpu.pprof，其中myservice是你的二进制文件路径 - Docker 部署时，别把二进制删了；交叉编译后记得保留原文件，用于线上分析
log.Printf 和 time.Now() 占比高？别优化算法，先砍日志
Web 火焰图里大量扁平分支指向 log.Printf、fmt.Sprintf 或 time.Now()，说明热点不在业务逻辑，而在日志和时间获取本身。
-
log.Printf内部会做锁 + 字符串拼接 + 内存分配，压测时极易成为瓶颈 - 替换方案：用
zap.Sugar()，并加条件包裹，例如if level >= Debug { logger.Debug(... ) } -
time.Now()调用本身不慢，但若每毫秒都调（比如在 tight loop 里），累积开销可观；考虑缓存时间戳或用单调时钟runtime.nanotime() - 高频 JSON 序列化也类似：别急着重写 marshaler，先检查是否重复序列化同一结构体，或能否复用
bytes.Buffer
最常被忽略的一点：pprof 的 heap 和 allocs 是两套指标，混用就会误判；查泄漏看多次 ?gc=1 的 InuseSpace 差值，查源头看 ?alloc_space=1 的累计分配排名 —— 两者目标不同，不能互相替代。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
