Go goroutine 因为没人接收 channel 为什么泄漏

Go 里最容易被忽略的一类 goroutine 泄漏，是发送方一直执行 ch ，但接收方已经返回、停止消费，或者根本没有被启动。无缓冲 channel 会等到发送者和接收者同时就绪；有缓冲 channel 也只是在容量耗尽前暂时遮住问题。一旦等待条件永远不会再次成立，goroutine 就不会自行消失。

修复的关键不是给 channel 随意加 buffer，而是让每一次可能阻塞的发送都同时拥有取消出口，并由上层明确负责停止、关闭和等待。

线上症状通常不是“goroutine 太多”这么简单

常见现场是：请求处理函数启动一个生产 goroutine，消费者只取第一条结果就返回。生产者第二次发送时没有接收方，于是堆栈长期停在 channel send。若生产者还持有请求参数、缓存对象或网络响应，泄漏的代价会随着请求次数累积。

排查时先记录 goroutine 数量趋势，再看 profile 中是否有大量 goroutine 停在发送表达式。一次短暂阻塞不等于泄漏，真正的判断是：接收方是否已经结束，是否仍有路径会关闭或取消，以及这个条件在业务生命周期内还能不能发生。

无缓冲和满缓冲都会把发送方卡住

下面的代码把问题缩小到最小：调用方只接收第一条结果，生产者随后没有机会完成第二次发送。这里的注释解释的是示例边界，不代表已经在本机执行过。

func produce() 

把 make(chan int, 2) 换成缓冲 channel 只会让这段示例暂时不显症状；当发送量超过容量，或者消费者提前退出，阻塞仍会出现。nil channel 更要谨慎：对它发送或接收都不会就绪。

让每次发送都能响应取消

如果下游可能提前返回，就把取消信号和发送动作放在同一个 select 中。这样发送方要么把值交给接收者，要么在上下文结束时退出；退出分支中的 return 是防止 goroutine 留下来的关键。

func produce(ctx context.Context) 

实际函数里通常由拥有这次操作的上层调用 cancel()，而不是让底层生产者反过来取消调用者。若读取结果本身也可能等待，应在接收处同样监听 ctx.Done()，否则消费者也可能泄漏。

关闭、等待和取消要分清责任

多个发送方时，不要让每个发送方都关闭同一个 channel；应由协调者等待所有发送方完成后统一关闭。任何一条发送路径都必须能到达完成或取消分支，不能只在“正常消费全部结果”的理想路径上安全。

修复后用四个问题复查

第一，消费者只取一条结果时，生产方是否仍能收到取消并返回？第二，所有发送分支是否都包含取消出口？第三，关闭者是否唯一，且不会与其他 goroutine 竞争 close？第四，测试结束前是否等待并确认相关 goroutine 已退出？这四问都能回答清楚，才说明修复的是生命周期，而不是用 buffer 把故障推迟。

相关问题

给 channel 加大容量能彻底解决泄漏吗？

不能。容量只改变允许暂存的数量，不能替代取消协议；当生产速度、结果数量或提前返回条件变化时，发送仍可能阻塞。

应该由接收方关闭 channel 吗？

通常不应该。接收方只表达“不再需要”，应通过取消或专用完成信号通知发送方；真正知道所有发送已结束的协调者再统一关闭。