goroutine 泄漏已发生，pprof /debug/pprof/goroutine?debug=2 可确认：若见 432000s（5天）等超长阻塞时长，且 chan receive/select 状态数持续单增，即为泄漏；重点排查 ssh、http readloop/writeloop 及自定义 channel 退出路径。
Go 服务上线后 goroutine 数持续上涨、内存缓慢增长、pprof 显示大量 chan receive 或 select 阻塞超过数小时——基本可以确定是 goroutine 泄漏，不是“可能”，而是“已经发生”。
怎么用 pprof 快速确认泄漏存在
pprof 的 /debug/pprof/goroutine 是第一道筛子，但很多人只看 ?debug=1 摘要，漏掉关键线索：
-
?debug=1只显示 goroutine 状态分布，重点盯住同一状态（如chan receive、select、IO wait）的数量是否随时间单向增长 -
?debug=2才暴露完整调用栈和阻塞时长；注意看时间字段——若出现432000s（5 天）、1209600s（14 天）这种量级，几乎 100% 是泄漏，不是慢操作 - 阻塞位置若集中在
golang.org/x/crypto/ssh、net/http的readLoop/writeLoop、或自定义 channel 操作，优先查对应逻辑的退出路径
为什么 goleak 在测试阶段更有效
pprof 是事后诊断，goleak 是事前拦截。它不依赖运行时状态，而是靠测试前后 goroutine 快照比对：
-
defer goleak.VerifyNone(t)放在单个 test 函数开头，适合快速验证修复效果；但要注意：它无法捕获被t.Parallel()干扰的 goroutine 生命周期 -
goleak.VerifyTestMain(m)放在TestMain中，能覆盖整个测试包，避免每个 test 都写重复代码；但需确保所有 goroutine 都在 test 结束前退出（比如显式close(ch)、cancel()） - 常见误报点：
time.AfterFunc、http.Serve启动的 server、未 mock 的第三方 client 内部 goroutine；这些需用goleak.IgnoreTopFunction过滤
goroutineleak（Go 1.25+ 实验特性）怎么启用
这是 GC 层面原生支持的泄露检测，比 goleak 更底层、比 pprof 更早发现，但目前仅存在于 gotip：
- 必须用
gotip运行：先执行go install golang.org/dl/gotip@latest，再gotip download - 启动时加环境变量：
GODEBUG=gctrace=1,GOROUTINELEAK=1，GC 日志中会出现found leaked goroutine提示 - 结果通过新端点暴露：
curl http://localhost:6060/debug/pprof/goroutineleak?debug=2，输出带_Gleaked状态标记的 goroutine 栈 - 注意：它只检测「阻塞在不可达同步原语上」的 goroutine，对死循环、无限重试等主动不退出场景无效
最容易被忽略的泄漏点：http.Response.Body
很多人以为 resp.Body.Close() 只是释放连接，其实它直接影响底层 persistConn 的生命周期：
- 完整读取响应体（如
io.ReadAll(resp.Body)）后不Close()，不会泄漏 goroutine；但若只读前 N 字节就丢弃 resp，且未Close()，则readLoopgoroutine 会永远卡在reqch上等待下个请求 - 使用
http.Client时，务必确保每个Do()或Get()后都有defer resp.Body.Close()，哪怕你马上 panic 也要执行 - mock HTTP client 测试时，如果用
httptest.NewServer，它的 handler 返回的ResponseWriter不需要 Close，但真实 client 调用仍要按规则处理
真正难排查的从来不是“有没有泄漏”，而是“泄漏 Goroutine 的退出条件是否被所有分支覆盖”——比如 context cancel 被 defer 掉、channel close 被 if 分支跳过、或者 select default 分支里忘了 break。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
