Go 1.27 goroutineleak 能查出哪些泄漏：全局变量为何会让 profile 漏报

服务看起来没有明显的 CPU 飙升，但请求越来越慢，排查时却发现某些 goroutine 长时间卡在 channel 或锁上。Go 1.27 的 runtime/pprof 增加了正式的 goroutineleak profile，可以帮助发现一大类“永远醒不过来”的 goroutine；它不是把所有阻塞都列出来，而是把并发原语的可达性也纳入判断。

为什么 goroutineleak 不是所有卡死的放大镜

官方说明把 goroutineleak 定义为泄漏 goroutine 的栈信息。这里的“泄漏”有一个严格前提：goroutine 被 channel、sync.Mutex、sync.Cond 等并发原语阻塞，而且从仍可运行的 goroutine 出发，已经找不到能够让它恢复的路径。

这和普通的 goroutine profile 不同。后者回答“现在有哪些 goroutine、它们停在哪里”，前者试图回答“哪些阻塞已经没有唤醒可能”。因此，看到 profile 没有报告，并不能直接证明服务没有泄漏；它只说明这类基于可达性的判断没有确认到目标。

从 runtime/pprof 到可达性判断，检查链条是什么

在 Go 1.27 中，runtime/pprof 的预定义 profile 列表包含 goroutineleak；HTTP 诊断入口也提供 /debug/pprof/goroutineleak。读到这条结果时，建议先把它当作“运行时识别出的一个子集”，再回到业务代码核对。

判断可以拆成三层：第一层是 goroutine 是否停在阻塞原语上；第二层是这个原语是否仍被某个可运行的对象引用；第三层是现有 goroutine 是否还拥有解除阻塞的机会。前两层都成立，并不等于第三层一定成立，尤其是存在全局状态、后台管理协程或间接引用时。

全局变量为何让泄漏变成漏报

假设一个后台 goroutine 永久等待 globalQ，而 globalQ 由全局变量持有。即使业务上已经没有任何发送方，垃圾回收仍然能从全局变量找到这个 channel。按照官方文档描述的可达性模型，并发原语并未变成不可达对象，goroutineleak 就可能不把它列为泄漏。

var globalQ = make(chan string)

func startWorker() {
    go func() {
        for {
            msg := 

这段代码只用来说明引用边界：它没有退出信号，也没有发送方，但全局引用仍在。生产排查还要确认循环是否真的有其他解除路径，不能只凭一个示例就断言 profile 一定漏报。

把排查结论落到工程检查

第一步看 /debug/pprof/goroutineleak 或直接读取对应 profile 的栈，记录阻塞原语、创建函数和业务对象。第二步在代码中搜索该 channel、锁或条件变量的所有持有者，尤其检查包级变量、管理器单例和仍在工作的后台 goroutine。第三步核对退出契约：请求取消是否能传到 worker，关闭时是否关闭输入，超时后是否仍有发送方等待。

如果 profile 没有条目，但 goroutine 数持续增长，优先补看普通 goroutine profile、堆栈采样和业务指标。一个合理的判断应同时满足“栈位置解释得通”“引用关系解释得通”“退出或回收路径能复查”，而不是把空结果当成通过。

常见问题

goroutineleak 和 goroutine profile 应该先看哪个？

有明确的 goroutine 持续增长或停机不干净时先看 goroutineleak；没有命中时再用普通 goroutine profile 观察所有等待点。

全局 channel 一定会被 goroutineleak 漏掉吗？

不一定。全局引用只是让并发原语保持可达，是否命中还取决于其他引用关系和运行时判断，工程上应把它当作可能漏报的边界。

升级 Go 1.27 后可以只靠这个 profile 做泄漏门禁吗？

不建议。它适合发现一类永久阻塞，门禁还应结合 goroutine 数、关闭路径、超时测试和普通 profile 做交叉核对。

一句话收尾：goroutineleak 解决的是“哪些阻塞已经不可能恢复”的识别问题；当 channel 或锁仍被全局状态保持可达时，空 profile 只是一个线索，不是最终结论。