Go 1.27 goroutineleak 怎么看：为什么可达对象会让检测失效

线上服务出现协程数量持续上涨时，Go 1.27 的 goroutineleak profile 可以先帮你筛出一大类“永远醒不过来”的阻塞协程。它依赖垃圾回收器做可达性判断，所以当阻塞原语仍被全局变量或可运行协程持有时，结果可能为空；空结果不能直接证明服务没有泄漏。

把它当作一项有边界的证据：先确认阻塞点，再确认阻塞原语是否仍可达，最后把 profile 结果与业务生命周期、请求日志和退出路径对照。

先分清“数量变多”和“永远醒不过来”

一个请求慢、队列积压或定时任务重入，都可能让协程短时间增加。真正适合交给 goroutineleak 观察的，是协程已经卡在并发原语上，而且从运行中的协程集合看不到任何可能唤醒它的路径。

Go 1.27 的官方说明把这项判断建立在可达性上：如果协程 G 卡在并发原语 P，而 P 不再能从可运行协程或这些协程能够唤醒的对象抵达，那么 G 没有机会恢复。这里的“没有机会”是运行时基于对象关系作出的判断，不等同于业务层面的超时统计。

哪些阻塞关系会进入 goroutineleak 证据

channel、Mutex 和 Cond 是判断入口

官方发布说明明确列举了 channel、sync.Mutex、sync.Cond 等并发原语。文章中的关键不是记住一份完整名单，而是先从堆栈确认协程确实卡在这类同步点，再检查同步点本身是否还被活跃对象持有。

因此，看到协程数量高时，先记下三件事：阻塞协程的创建位置、当前等待的原语、以及负责释放或唤醒它的对象。少了第三项，profile 只能告诉你现象，不能帮你恢复业务生命周期。

net/http/pprof 入口和 runtime/pprof API 不是一回事

runtime/pprof 提供 profile 类型，net/http/pprof 则把标准 profile 通过调试 HTTP 端点提供出来。Go 1.27 发布说明列出 /debug/pprof/goroutineleak；部署时仍要按自己的路由、鉴权和网络边界确认 HTTP入口 是否真的暴露，不能只因为导入了 pprof 就假设外部一定可访问。

这里的 HTTP入口只是访问边界，真正的 profile 类型仍由 runtime/pprof 提供。

为什么全局可达对象会制造盲区

这正是最容易误读的地方：如果阻塞原语仍能通过全局变量到达，或者被某个可运行协程的局部变量持有，运行时可能无法判定它永远无法唤醒。此时 profile 没有列出某个协程，并不等于它的业务退出路径正确，只能说明当前检测条件没有闭合。

例如，一个全局 worker registry 仍保存着队列对象，队列内部的等待 channel 即便长期没有业务生产者，也可能保持可达。排查这类现象要回到所有权：谁创建 worker，谁在取消时关闭输入，谁移除 registry 引用，谁负责等待退出。不要用一条“profile 为空”的结论替代这些问题。

把 profile 结果放进一次可复查的排查记录

建议将采样时间、服务实例、入口权限范围、profile 返回的协程线索和对应的业务对象写在同一条记录中。若没有结果，也要记录当时的协程总量、请求流量和正在运行的 worker 数量，方便下一次对照。

对于生产环境，调试端点应放在受控网络或经过鉴权的运维入口后面。profile 是诊断数据，可能暴露包名、函数名和业务调用关系；不要为了“方便查看”把 pprof 端口直接绑到公网。

常见问题

profile 没有条目，是否代表没有协程泄漏？

不是。可达对象、全局引用和可运行协程都会影响运行时的判断范围。应当把 profile 结果与协程生命周期、取消信号、队列清理和进程退出测试一起看。

goroutine profile 和 goroutineleak profile 能互相替代吗？

不能。普通 goroutine profile 更适合观察当前协程堆栈与数量，goroutineleak 则针对一类基于永久阻塞和可达性推断的泄漏。两者回答的问题不同，最好在同一时间窗口采集并比对。

升级到 Go 1.27 后要立刻改 worker 代码吗？

不需要因为新增 profile 就重写所有并发代码。先把它作为诊断工具接入既有告警和退出检查，再针对明确的阻塞点补取消、关闭、移除引用或等待回收逻辑。

一份足够小的验收清单

• 确认运行时和构建模块使用 Go 1.27 或更高版本，并核对入口对应的官方 profile 名称。
• 每次采样同时保存协程数量、关键堆栈、业务对象所有权和入口访问范围。
• 对“无条目”结论保留可达性假设，不把它写成“零泄漏证明”。
• 修复后重复观察创建、取消、关闭和退出四个生命周期节点。

这项能力最有价值的地方，是把“协程越来越多”的模糊症状缩小到一组可解释的阻塞关系；它的限制也同样重要：运行时能证明的范围，永远小于业务团队想问的全部问题。