Go goroutine 因 channel 无接收者阻塞怎么排查

Go goroutine 卡在 channel 发送时，先从 goroutine 栈找到业务发送点，再确认接收者是否已提前返回、缓冲区是否已满，以及通道是否为 nil。若接收方已经不再需要结果，修复重点是让发送方能感知取消并退出；直接关闭结果通道可能让仍在发送的协程 panic。

官方文档地址：https://pkg.go.dev/runtime/pprof

确认发送阻塞而非正常等待

无缓冲通道需要收发双方配对；有缓冲通道在空间耗尽后也会等待。短暂等待通常是正常背压。真正需要排查的是：请求或任务已经结束，相关发送协程仍反复滞留在同一个业务位置，后续任务又不断创建新的同类协程。

一个常见场景是调用方只读取第一个成功结果就返回，但生产者还要继续发送剩余结果。只要通道没有接收者，剩余发送就可能一直等下去。即使业务对象不再引用该通道，阻塞协程也不会因此自动消失；应为它设计可到达的退出条件。

采集 goroutine 栈定位业务发送点

把下面的函数接入已有的受控诊断入口，输出到日志或由调用方管理的文件。它仅生成当前协程快照，不会终止协程，也不需要为排查临时开放公共 HTTP 端口。

package diag

import (
    "io"
    "runtime/pprof"
)

// DumpGoroutines 接入已有的受控诊断入口，由调用方管理输出文件。
func DumpGoroutines(w io.Writer) error {
    // debug=2 输出带协程状态的可读调用栈。
    return pprof.Lookup("goroutine").WriteTo(w, 2)
}

先找 chan send 状态附近的业务函数和源码行，再沿创建栈确认谁启动了协程。若发送放在 select 中，栈状态可能显示 select，需要回到源码看每个分支。不要把某次快照中的一个等待状态直接当成泄漏结论。

在任务结束前后各保留快照，按业务调用点归组，观察相关等待是否随任务完成而消失。接着查接收方的提前返回、超时、错误分支，以及生产者是否收到同一个取消信号。正在等待的协程本身就可能长期不返回，因此仅依赖“已经结束的阻塞事件”统计不能代替当前 goroutine 栈。

把取消接入发送等待

只在循环开始检查取消，然后执行普通发送，仍可能在下一次发送处卡住。应把发送和取消放进同一个 select，让没有接收者时仍有退出分支。下面是独立的最小示例：数据来自有限切片，调用方只取首个值，然后取消并等待生产者完成。

package main

import (
    "context"
    "fmt"
)

// Stream 返回只读结果和完成通知，调用方不关闭结果通道。
func Stream(ctx context.Context, values []int) (

保存为 main.go 后，可自行运行：

# 运行有限输入示例，观察首个结果和正常退出。
go run main.go

示例预期输出首个值 12，然后结束；这里没有把示例描述为本机实测。取消后若发送与取消同时就绪，select 并不保证优先选择取消，所以不能承诺取消后绝不会再交付一个值。业务如有严格的交付截止语义，还需单独设计协议。

明确关闭和等待责任

示例里调用方拥有 cancel，生产者拥有 out 和 done 的关闭责任。cancel 发出取消通知，done 表示生产者已完成退出，两者含义不同。结果通道的关闭通知接收方不会再有新值，不能作为“让发送者安全退出”的替代动作。

有多个发送者时，通常由一个协调者在确认全部发送者结束之后统一关闭结果通道。不能让每个发送者都自行关闭同一个通道，也不能让接收方在仍可能有发送时贸然关闭。已有的 WaitGroup 可承担等待责任，但它本身不会打断阻塞发送，退出分支仍然需要存在。

如果生产者在发送前还会阻塞读取上游或等待 I/O，也必须给这些等待设计退出方式。示例的有限切片没有这个问题；把切片换成通道后，普通 range 等待上游值就可能成为新的滞留点。

排查修复后的生命周期及常见误区

复现下游提前退出和取消场景时，应观察完成通知是否到达，以及对应业务发送栈是否消失。保留正常消费全部结果的路径，确认取消处理没有损坏完整输出。不要只看全局 goroutine 总数回到某个固定值，运行时及其他组件也可能持有正常后台协程。

增加 channel 缓冲是否就能修好？只有未消费结果数量存在可靠上界时，缓冲才可能承担明确设计的容量责任。随手增大容量通常只是延后阻塞，输入继续增长或消费者更早退出后仍会遇到同一问题。

有 defer close 就能保证关闭吗？不能。若协程卡在无法退出的发送处，函数没有返回，defer 就无法执行。必须先保证阻塞点能走到退出路径。

加 default 跳过发送可以吗？可以实现明确允许丢弃的协议，但会改变结果交付语义。需要可靠交付时，应使用取消、背压和生命周期约定；不要把静默丢弃当成通用排障修复。

排查时把发送点、接收者去向、取消来源和关闭责任对应起来，才能判断等待是正常背压还是失去退出机会的滞留。

参考：Go 发送语句规范；goroutine 快照格式；Go 流水线取消设计。