协程泄漏是因goroutine阻塞在不可达同步原语上导致持续增长，需通过numgoroutine监控、debug=2堆栈分析、三类典型调用链定位，并用goleak和goroutineleak端点左移拦截与线上检测。
线上服务内存持续上涨、Pod被OOMKilled、监控曲线呈现30度斜线式爬升，runtime.NumGoroutine()从42飙到1867却不再回落——这不是GC延迟，是协程泄漏已钉住大对象，必须立刻定位阻塞点并切断泄漏路径。
确认是否为协程泄漏而非内存分配抖动
第一步：在HTTP handler入口和返回处各加一行日志：log.Printf("goroutines: %d", runtime.NumGoroutine())。
第二步：发起单次请求，观察数字变化。若handler返回后数值未回落（比如入口85 → handler内峰值92 → 返回后仍为92），基本可判定泄漏已发生。
第三步：压测结束后等待30秒，再查一次总数。若比空闲态高300+且堆栈中大量出现chan receive或select状态，无需继续看heap profile——这就是协程泄漏，不是内存泄漏。
注意：?debug=1只返回统计摘要，看不到具体卡在哪；必须用?debug=2才能拿到完整堆栈和阻塞时长，出现432000s这种量级，几乎100%是泄漏。
用GoLand快速抓取并分析goroutine阻塞堆栈
方法一：通过内置pprof服务直接访问
启动服务时确保已导入_ "net/http/pprof"，并在独立goroutine中运行http.ListenAndServe("localhost:6060", nil)。
在GoLand的Terminal中执行：wget http://localhost:6060/debug/pprof/goroutine?debug=2 -O goroutine-blocked.gor。
方法二：用GoLand Profiler界面一键采集
点击菜单Run → Start Profiling → Select Profiling Type → 选择Goroutines → 点击Start。
等待10秒后点击Stop，GoLand会自动生成火焰图和goroutine列表，双击任意条目即可跳转到源码行。
【关键操作】在火焰图中右键任意节点 → “Filter by Stack Trace” → 输入chan receive或time.Sleep，立即聚焦泄漏高发区。
定位泄漏源头的三类典型调用链
① 向已关闭channel发送数据
堆栈末尾常见runtime.chansend1 → 上层调用链含client.go:72或worker.go:45，且该函数启动了goroutine但未做close兜底——sender panic退出时忘了close(ch)，receiver永久阻塞。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
② context未监听Done信号
调用链中夹着http.Do、db.QueryRow或time.AfterFunc，但外围缺少select { case 分支。闭包捕获的ctx可能已被cancel，但goroutine仍在死等IO。
③ timer/ticker未Stop
堆栈含timerproc或timeSleep，且上层函数无defer ticker.Stop()或未在select退出分支中显式调用ticker.Stop()。panic发生时defer不执行，泄漏即成定局。
用goleak在测试阶段左移拦截
方法一：在TestMain中集成验证
在func TestMain(m *testing.M)末尾添加os.Exit(m.Run())前插入：goleak.VerifyNone(m, goleak.IgnoreCurrent())。
方法二：单测函数内临时启用
在测试函数开头加defer goleak.VerifyNone(t)，运行go test -v ./... -run TestXXX，失败时直接输出泄漏goroutine初始调用栈。
这一步操作起来很简单，直接把文件拖进去就行。
线上启用goroutineleak端点（Go 1.24+）
启动服务前设置环境变量：GODEBUG=goleak=1。
代码中首次访问/debug/pprof/goroutineleak前，必须手动触发一次GC：runtime.GC()，否则返回为空。
访问http://localhost:6060/debug/pprof/goroutineleak?debug=1，响应体中带_Gleaked状态的goroutine即为确定泄露项。
【重要前提】该端点只检测“阻塞在不可达同步原语上”的协程，对无限for循环或重试逻辑无效。
