协程泄漏表现为goroutine数持续上涨且不回落、内存缓慢爬升、服务静默无panic，而死锁会立即触发fatal error；需通过runtime.numgoroutine()趋势监控和/debug/pprof/goroutine?debug=2堆栈分析确认，重点关注chan receive/select等阻塞状态。
GoLand里怎么确认是协程泄漏而不是死锁
死锁会立刻panic，报fatal error: all goroutines are asleep - deadlock!；协程泄漏则完全静默，服务照常响应但内存和goroutine数缓慢爬升。如果你看到Pod被OOMKilled、runtime.NumGoroutine()从50涨到2000+且不回落、监控曲线呈30度斜线——这不是死锁，是协程泄漏在钉住内存。
在GoLand里抓goroutine堆栈的两种实操路径
别等线上炸了才查。本地复现时，优先用GoLand内置Profiler，它比手敲curl更稳：
- 确保项目已导入
_ "net/http/pprof"，并在main()里起pprof服务：go http.ListenAndServe("localhost:6060", nil) - Run → Start Profiling → 选Goroutines → Start，等10秒后Stop，GoLand自动解析火焰图和goroutine列表
- 右键火焰图节点 → Filter by Stack Trace → 输入
chan receive或select，直接聚焦阻塞点 - 如果想导出文本分析，终端执行：
wget http://localhost:6060/debug/pprof/goroutine?debug=2 -O goroutine-blocked.gor（注意必须是?debug=2，?debug=1只给总数）
定位泄漏源头时最容易忽略的三类调用链
堆栈里反复出现同一函数？别急着改逻辑，先看是不是这三类典型模式：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
runtime.chansend1往上追到client.go:72：向已关闭或nil channel发数据，sender panic退出却没close(ch)，receiver永久卡在 - 堆栈含
http.Do或db.QueryRow，但外围没select { case ：闭包捕获的context已被cancel，goroutine还在死等IO - 出现
timerproc或timeSleep，上层函数没defer ticker.Stop()：ticker没停，每秒都在启新goroutine
goleak验证总失败？检查这四个执行细节
goleak.VerifyNone(t)不是加了就管用，常见失效原因全是执行时机问题：
- 必须写成
defer goleak.VerifyNone(t)，写成普通调用会漏掉panic路径 - 别把
defer放在test函数开头就return的逻辑前——待测goroutine根本没跑完就被检查了 - 合法后台服务如
net/http.(*Server).Serve要显式忽略：goleak.IgnoreTopFunction("net/http.(*Server).Serve")，漏掉包名或括号都不生效 - 测试里起了
time.Ticker，得先ticker.Stop()再让VerifyNone检查，否则它真会当成泄漏报出来
真正麻烦的不是堆栈难读，而是泄漏goroutine往往混在几十个正常后台协程里——比如pprof/goroutineleak端点（Go 1.24+需GODEBUG=goleak=1）只报“不可达同步原语”类泄漏，对死循环或无限重试完全不敏感。盯住chan receive (nil chan)和select状态，比数总数更有价值。
