pprof服务必须在main启动后尽早启用http server，而非仅靠import _ "net/http/pprof"注册handler；若listenandserve延迟或被defer包裹，将错过早期goroutine泄漏窗口，建议将其置于main开头并早于任何业务goroutine启动。
pprof 服务必须在 main 启动前注册，否则 /debug/pprof 不生效
Go 的 net/http/pprof 是个“被动注入”式包，import _ "net/http/pprof" 只是注册 handler，不启动 HTTP server；如果 http.ListenAndServe 晚于业务逻辑启动（比如塞在某个 init 函数里、或被 defer 包裹），就可能错过早期 goroutine 泄漏窗口。
实操建议：
- 把
http.ListenAndServe("localhost:6060", nil)放在main()开头，或至少早于任何业务 goroutine 启动 - 别用
go func() { http.ListenAndServe(...) }()—— 这种写法容易因 panic 或提前 return 导致 server 没起来 - 若服务已用其他端口（如 :8080），可复用同一 mux：
http.DefaultServeMux.Handle("/debug/", http.StripPrefix("/debug/", http.HandlerFunc(pprof.Index))) - 线上环境务必加
runtime.GC()在首次访问/debug/pprof/goroutineleak前，否则 Go 1.24+ 的goroutineleak端点返回为空
编译时禁用默认守护协程需手动控制 runtime 启动行为
Go 标准库会在后台自动启一些协程：HTTP server 的 accept loop、GC worker、timerproc、finalizer goroutine……这些不是泄漏，但会干扰泄漏判断。想“干净”地观察业务协程，不能靠编译 flag 屏蔽——Go 没提供 -gc=false 这类开关。
可行路径只有两个：
- 用
runtime.LockOSThread()+runtime.GOMAXPROCS(1)限制调度器规模，再手动调用runtime.GC()清掉初始堆栈，适合单测隔离场景 - 启动后立刻抓一次
/debug/pprof/goroutine?debug=2快照，作为 baseline，后续比对只关注新增 goroutine 的调用链末尾是否含业务函数名 - 避免在 init 阶段启动 HTTP client、DB 连接池、logrus hook 等——它们的 background reaper goroutine 会立刻污染 baseline
goroutineleak 端点依赖 GODEBUG=goleak=1，且仅检测不可达阻塞
/debug/pprof/goroutineleak 不是万能探测器。它只标记那些“永远无法被唤醒”的 goroutine：向已关闭 channel 发送、所有 select case 都不可达、等待已无引用的 mutex。死循环、无限重试、未设超时的 time.Sleep 都不会被标为 _Gleaked。
使用条件很硬：
- 必须设环境变量
GODEBUG=goleak=1，否则端点 404 - 首次访问前必须触发一次
runtime.GC()，否则返回空列表（Go 1.24+ 行为） - 返回结果里带
_Gleaked状态的 goroutine 才是确定泄漏项，其余只是活跃协程 - 它不替代
?debug=2的人工分析，而是补充——尤其适合 CI 流水线做自动化断言
本地复现时 heap profile 文件名必须带 .heap 后缀
go tool pprof 对文件扩展名有隐式校验。用 pprof.WriteHeapProfile(f) 写出的文件，若命名为 heap1 或 heap1.prof，go tool pprof heap1 会报错 unrecognized profile format，即使内容完全合法。
正确做法：
- 文件名强制用
.heap后缀：heap_before.heap、heap_after.heap - 采样时机避开 GC 高峰：
MemStats.HeapAlloc接近MemStats.NextGC时采样，数据失真严重 - 两次采样间隔至少 30 秒，且期间负载稳定；用
go tool pprof -base heap_before.heap heap_after.heap查净增长 - 浏览器打开后切到
SAMPLE=inuse_space→View → Difference，才能看到真正涨的部分
(*sql.DB).connPool 下挂着一个你没调 Close() 的 *sql.Conn，而它又被某个闭包捕获，最终卡在 net.Conn.Read 上。这时候光看 goroutine 数或 topN 分配，根本找不到根因。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
