真正内存泄漏的硬指标是：runtime.MemStats.HeapInuse持续单向增长，且pprof heap profile中某类对象的inuse_space随时间线性上升；goroutine泄漏则表现为select{}、
怎么一眼判断是不是真泄漏
别一看到内存涨就喊“泄漏”，Go里很多“内存上涨”只是缓存没控好、GC还没轮到、或者对象复用率低。真正泄漏的硬指标只有两个：runtime.MemStats.HeapInuse 持续单向增长，且 go tool pprof 的 heap profile 里某类对象（比如 *http.Request 或 []uint8）的 inuse_space 随时间线性上升。
- 访问
http://localhost:6060/debug/pprof/heap?debug=1看原始统计，重点关注inuse_space（不是alloc_space） - 用
go tool pprof http://localhost:6060/debug/pprof/heap进交互模式，先敲top -cum找调用链顶端函数 - 如果
inuse_space很小但alloc_space巨大，大概率是短期分配多、GC还没回收——试试手动触发runtime.GC()后再采样
pprof 必须加的两行代码和一个参数
很多人启了 net/http/pprof 却抓不到真实泄漏点，问题出在没显式触发堆采样或用了错误参数。HTTP 接口默认不强制 GC，所以采集到的可能是“带垃圾”的快照。
- 启动时必须加：
import _ "net/http/pprof"和go http.ListenAndServe("localhost:6060", nil) - 采集 heap 时一定要加
?gc=1：用go tool pprof http://localhost:6060/debug/pprof/heap?gc=1，否则可能把本该被回收的对象误判为泄漏 - 本地复现时别只靠 HTTP：可在疑似逻辑前后调
pprof.WriteHeapProfile(f)，文件后缀必须是.heap，否则go tool pprof无法识别
goroutine 泄漏才是内存涨得慢的真凶
90% 的“内存缓慢上涨”背后不是对象没释放，而是 goroutine 没退出，死死钉住一堆大对象——比如一个闭包捕获了含 []byte 的结构体，它活着，整个结构体就永远进不了 GC。
- 查 goroutine 不看默认页：
http://localhost:6060/debug/pprof/goroutine只给总数；必须用?debug=2才能看到完整堆栈 - 重点盯这些卡点：
select {}、（无缓冲 channel receive）、<code>time.Sleep、for range ch（但ch永远不关） - 示例陷阱：
func badWorker(ch —— 只要 <code>ch不关，这个 goroutine 就永生
map 和 sync.Map 是最常被忽略的泄漏源
普通 map 不会自动清理键值对，sync.Map 更不会。用时间戳、请求 ID、UUID 当 key，又从不 delete，等于自己造了个内存黑洞。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖“程序结束时自动清”，服务长期运行，map 会越胀越大
- 缓存场景优先选带 TTL 的库（如
github.com/bluele/gcache），而不是手写map+time.AfterFunc - 如果必须用 map，作用域结束前主动清空：
for k := range m { delete(m, k) }；value 别直接塞大结构体，改用指针或 ID - 特别警惕日志中间件、trace 上下文里临时拼的
map[string]interface{}，它们极易被遗忘
pprof 不会告诉你哪行代码漏了，它只负责暴露“谁在持续吃内存”和“谁一直活着不走”。真正的难点从来不在工具怎么用，而在你是否愿意顺着 top 函数往下调用链一层层 list，直到看见那个没关的 channel、那个忘了 stop 的 ticker、或者那个永远没被 delete 的 map key。
