goroutine 泄漏剖析里等待状态很多就一定泄漏吗

不一定。要先确认你看的是什么 profile：普通 goroutine profile 里的 [chan receive]、[select] 或 waiting 只说明采样时正在阻塞，正常 worker 在没有任务时也会这样；Go 1.27 的 goroutineleak profile 则经过运行时的活性分析，非空结果表示这些样本在支持的并发原语范围内已被判定为泄漏。

即使如此，“泄漏样本多”仍不等于已经知道根因和业务影响。正确的排查顺序是：辨认 profile 类型，再看同栈数量是否持续累积、是否随流量回落、阻塞原语是否还有可达的唤醒者，以及 goroutine 是否持有明显资源。

官方资料：https://go.dev/blog/goroutine-leak-profiles

先看 profile 类型：waiting 多不等于泄漏

普通 goroutine profile 的用途是展示当前 goroutine 的调用栈与阻塞状态。它能帮助发现“某类阻塞很多”，却不能自动区分暂时阻塞和永远无法解除的阻塞。微服务流量升高时，连接处理、任务队列、限流器或批处理 worker 都可能让相同 waiting 栈短期增加。

goroutineleak profile 的语义不同。Go 运行时从可运行 goroutine 出发，追踪它们能到达的 channel 与 sync 原语；如果一个 goroutine 永久阻塞，且没有活跃 goroutine 能再触达其解除阻塞所需的原语，它才会被筛入泄漏 profile。它减少了“正常等待被误判”的问题，但检测范围是一个明确子集。

建立基线：等待数量必须和业务流量一起看

不要先给“waiting 超过多少就是泄漏”设一个通用阈值。不同服务的并发模型差异很大：固定 worker 池可能长期保留数百个等待 goroutine，而低流量定时任务出现十几个同栈增长就值得检查。更可靠的方法是在同一版本、同一采集方式下记录自己的基线。

采集命令也要保持一致。下面分别保存普通 goroutine profile 和泄漏 profile，避免把两个端点的结果混在同一张趋势图里：

# 保存普通 goroutine profile，用于观察所有阻塞栈
curl -s http://localhost:6060/debug/pprof/goroutine -o goroutine.prof

# 保存 Go 1.27 泄漏 profile，只看运行时判定的泄漏样本
curl -s http://localhost:6060/debug/pprof/goroutineleak -o leak.prof

# 分别查看聚合结果，文件名要保留 profile 语义
go tool pprof -top goroutine.prof
go tool pprof -top leak.prof

对照示例：正常 worker 也会长期显示 waiting

下面的 worker 池在没有任务时会阻塞在 select。只要服务仍持有 jobs 和 cancel，就存在发送任务或取消 worker 的路径。普通 goroutine profile 里看到很多相同 waiting 栈是预期状态，不能仅凭数量判泄漏。

func startWorkers(ctx context.Context, jobs 

核对点有三个：worker 数量是否与配置一致；低流量时是否稳定而不是单向增长；关闭 ctx 后是否能退出。三项都满足时，waiting 更可能是池化并发的正常静止状态。

泄漏样本：无人接收的发送会怎样被筛出

另一个极简函数创建无缓冲 channel，启动发送者后立即返回。调用者不保留 channel，也没有接收者；发送 goroutine 永远等不到配对操作。这种“阻塞原语只剩泄漏 goroutine 自己持有”的情况，正是泄漏 profiler 能识别的典型模式。

func spawnOrphanSender() {
	ch := make(chan struct{})
	go func() {
		ch 

在普通 profile 中，这个发送者同样只显示为等待；在 goroutineleak profile 中，运行时会把它列为泄漏样本。用 list 回到代码行时，看到的是阻塞操作，不一定直接看到“为什么没有接收者”。因此还要顺着创建点、错误分支、超时分支和生命周期拥有者继续追根因。

# 先找样本集中的函数，再映射到阻塞代码行
go tool pprof -top leak.prof
go tool pprof -list=spawnOrphanSender leak.prof

结果对比：四类证据决定排查优先级

把结论拆成四类证据，可以避免“看到 waiting 就修代码”和“profile 为空就宣布安全”这两种极端。

• 类型证据：普通 profile 只证明正在等待；goroutineleak 非空证明支持范围内已发现泄漏。
• 趋势证据：同一栈是否随每次请求、超时或错误不断增加，并且在负载下降后不回落。
• 生命周期证据：负责发送、关闭、取消或解锁的拥有者是否已经退出，引用是否只剩阻塞 goroutine 自己持有。
• 影响证据：泄漏 goroutine 是否引用大对象、连接、缓冲区或请求上下文，是否带来内存和 GC 压力。

如果普通 profile waiting 很多，但数量随流量回落、拥有者仍可取消、资源使用稳定，优先把它当正常等待核对。如果 goroutineleak 非空且同栈持续增加，应直接追踪阻塞行与创建路径。若泄漏数量不多但每个 goroutine 引用大缓冲区或连接，也应提高优先级，不能只按样本数排序。

边界条件：非空不是完整根因，空也不是安全证明

goroutineleak 的非空结果已经比普通 waiting 更强，但它仍只告诉你“这些 goroutine 无法被支持的原语唤醒”以及阻塞位置。真正的代码错误可能是遗漏 return、提前返回、没有关闭 channel、忘记调用 Stop，或者接口调用顺序被破坏，需要回到所有权与控制流中确认。

空结果的边界更需要记住。官方说明目前不会把文件 I/O、网络 I/O、直接系统调用或自定义自旋锁上的阻塞判为泄漏。如果某个 channel 或锁仍能从全局变量、可运行 goroutine 到达，运行时也会保守地认为它仍可能被使用，即使业务上已经没人会触发它。

还有一类缺陷只有特定竞态、超时或错误分支触发。没有复现就没有泄漏样本，所以生产 profile 应和测试中的 goleak、synctest、生命周期日志及普通 goroutine 趋势配合使用。采集端口应限制在回环地址或受控管理网络，避免把 pprof 无保护地开放到公网。

常见问题

goroutineleak profile 里出现一个样本也算泄漏吗？

在该 profiler 支持的检测语义内，非空样本就是运行时判定的泄漏；但一个样本的业务风险取决于它持有的资源、触发频率和是否会继续累积。

普通 profile 里同一个 waiting 栈很多，应该先做什么？

先核对它是否来自固定 worker 池或随流量变化，再比较不同时间点的同栈数量，并检查是否存在取消、关闭或发送路径。不要先修改并发数量来掩盖趋势。

为什么逻辑上已经不会退出，却没出现在 leak profile？

可能阻塞发生在 I/O 或系统调用上，也可能 channel、锁仍被全局对象或活跃 goroutine 引用，运行时无法证明它永远不会被使用。

等待很多会直接造成高 CPU 吗？

纯阻塞 goroutine 通常不会像忙循环一样持续占用 CPU，但其栈和引用对象会占内存，数量累积后也会增加 GC 与调度相关成本。应结合内存、GC 和资源持有判断影响。

参考资料：Go 官方博客：Goroutine Leak Profiles、runtime/pprof、net/http/pprof。