Go channel 阻塞为什么不能直接算泄漏：普通 goroutine 栈与可达性证据的分工

线上 Go 服务里，channel 发送或接收变慢时，goroutine 数量往往也会一起上升。这个现象值得排查，却还不足以直接叫作“泄漏”：正常背压、等待外部 I/O 和永远不会被唤醒的 goroutine，都会出现在普通栈里。更稳妥的做法是先找阻塞现场，再用 Go 1.27 的 goroutineleak 证据缩小范围，最后回到业务生命周期确认修复。

普通 goroutine 栈负责告诉你“卡在哪里”，goroutineleak 负责回答“运行时能否证明它永远醒不过来”；两者都不能单独证明系统不存在所有泄漏。

先把 channel 阻塞与 goroutine 泄漏拆成两个待证命题

先问一个具体问题：这个 goroutine 是否还有明确的唤醒条件？例如，worker 在等 channel 输入，生产者可能只是暂时没有任务；HTTP 请求在等上游响应，也可能属于正常超时窗口。相反，如果发送方已经退出、接收方永远不会创建，或者持有锁的生命周期已经结束，阻塞才逐渐具备泄漏特征。

排查时记录三件事：阻塞原语是 channel、sync.Mutex 还是 sync.Cond；谁负责唤醒它；调用方退出时是否执行了取消、关闭或释放。这样能把“看起来卡住”转成可以验证的生命周期问题。

用普通 goroutine profile 找到等待原语和调用现场

普通 goroutine 栈适合做第一轮定位。通过 runtime/pprof 取得 profile，或在内部诊断服务注册 net/http/pprof 后查看完整栈，可以看到阻塞函数、等待原因和业务调用链。它的优点是信息全，缺点是合法等待也很多，所以不要把报告条目数直接当作泄漏数量。

实际复核可以保留类似下面的查询动作，但不要把一次抓取当成结论：

p := pprof.Lookup("goroutine")
if p != nil {
    _ = p.WriteTo(writer, 2)
}

报告中至少要能指出阻塞函数、等待原语和一条退出路径。诊断入口应绑定私有监听器并加访问控制，避免把调用栈和运行信息暴露给公网。

用 goroutineleak 验证运行时能否证明永久不可达

Go 1.27 将 goroutineleak profile 提升为可用能力，也能通过 net/http/pprof 的 /debug/pprof/goroutineleak 访问。它不是“所有卡住的 goroutine 列表”，而是借助垃圾回收器检查并发原语的可达性：如果阻塞在 channel、sync.Mutex 或 sync.Cond 上的 goroutine，其原语已经不再被任何可运行、能够唤醒它的路径触达，运行时才有机会把它归入可证明的泄漏。

这解释了两个容易相反的结果：profile 命中时，说明运行时已经拿到很强的永久阻塞证据；profile 为空时，只说明当前对象关系不足以完成这项证明。若 channel 或锁仍被全局变量、可运行 goroutine 的局部变量持有，检测可能看不到问题。因此它应与普通栈、请求取消记录和 worker 退出日志一起读。

把两份证据合成修复与上线清单

修复不要只围着 profile 输出删 goroutine。先补齐生命周期契约：谁创建 worker，谁发送结束信号，谁负责 cancel，谁关闭 channel，持锁方如何保证释放。修完后在相同负载和相同观察窗口再次采集普通 goroutine 栈与 goroutineleak，确认候选栈消失，同时业务请求仍能正常结束。

上线前的最小清单是：确认等待条件、保存两类 profile、核对 cancel/close/Unlock 路径、在私有诊断入口复测，并把“未被 goroutineleak 命中”标成待观察而不是“已证明安全”。

常见问题

看到 channel recv 阻塞，应该先改代码吗？

先找发送方和预期唤醒条件。若条件仍存在，可能只是背压；若调用方已经退出且没有取消或关闭路径，再进入修复。

goroutineleak 为空，是不是没有泄漏？

不是。它只覆盖运行时能依据可达性证明的永久阻塞，仍可达的全局对象和复杂生命周期需要普通栈、日志和业务契约继续核对。

生产环境可以公开 /debug/pprof/goroutineleak 吗？

不建议直接公开。把 net/http/pprof 放在私有监听器后，叠加网络访问控制和应用认证，只在受控排障窗口采集。