Go goroutine 为什么退出后 channel 仍然阻塞

Go goroutine 退出，不会自动关闭它使用的 channel。若另一端仍在等待数据，而通道既没有值也没有被关闭，接收就可能继续阻塞。反过来，接收者提前退出也不会通知发送者；无缓冲发送找不到接收者，或缓冲已满时，发送端仍会等待。

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

我先分清退出的是谁，等的是谁

我看这类问题时，会先把“某个 goroutine 打印了退出日志”和“整个通信协议已经结束”分开。一个工作者结束，不代表所有发送者结束；消费者返回，也不代表生产者已经知道不用继续发。下面用小型批处理场景说明这种判断，不声称来自真实线上事故。

// 发送者提前返回，但没有发送结果，也没有关闭通道。
ch := make(chan int)
go func() {
    return
}()
// ch仍为空且未关闭；若没有其他发送者，这个接收会一直等待。
value := 

这是刻意保留缺陷的函数内片段，不建议直接嵌进生产代码。逻辑上的问题是接收方没有结束信号；如果放进一个所有 goroutine 都无法继续的简单程序，运行时可能报告死锁。但在仍有服务器、计时器或其他活动的进程里，局部等待不一定触发全局死锁报告。

排查时还应确认通道不是 nil：nil channel 的发送与接收都无法自行继续。对于已关闭且排空的 channel，接收会立即得到元素零值和 ok=false，因此“收到零”本身不能说明还存在一条正常数据。

任务一多，缓冲只能推迟暴露问题

假设每份导入任务都启动一个 goroutine，各自把结果发给汇总者；汇总者只要第一条就返回。小数据时，缓冲也许能暂时容纳剩余结果；任务持续增长后，剩余发送者仍可能卡在满缓冲上。问题从单次等待变成越来越多任务无法结束，但这里没有实际 goroutine 数量或内存曲线可供宣称。

我的取舍是把“每项一个 goroutine”改成固定数量的工作者，把生产速度交给有界通信和取消协议共同控制。示例使用无缓冲 jobs、out，所以背压很明显；这不代表无缓冲一定更快，而是避免用随意加大容量来掩盖没有退出分支的问题。

关闭规则需要先写清楚：生产者是 jobs 唯一发送者，因此由它关闭 jobs；out 有多个工作者发送，不由某个单独工作者随意关闭，而由知道全部发送者已经退出的协调者关闭。消费者要提前停止，就取消任务，不直接 close(out)。

让协调者关闭结果，让取消覆盖发送

以下原创完整示例可保存为 main.go。它保留三名工作者，并让生产者发送、工作者接收及工作者发送结果都能观察同一 Context。为兼容常用写法，使用 WaitGroup.Add/Done，而不依赖较新的辅助接口。

package main

import (
    "context"
    "fmt"
    "sync"
)

type Result struct {
    Index int
    Value int
}

type job struct {
    index int
    value int
}

// start 接收非nil Context；调用方在stopped关闭前不得修改values。
func start(ctx context.Context, values []int) (

所有 Add 在启动 Wait 之前完成。协调者等待的是生产者和工作者组，不是自己；等待完成后才关闭 out，避免发送到已关闭通道。它最后关闭 stopped，向消费者确认这些受管理任务已经到达退出点。接到 stopped 关闭后，无须再依赖延时猜测。

main 在消费第一条结果后先 cancel，再等 stopped。若顺序反过来，工作者可能正在等 out 的接收者，消费者却在等工作者完成，又形成一个等待环。完整消费时则可以持续 range results，直到协调者关闭 out；提前停止消费时必须保留取消动作。

示例的计算是小整数乘二，仅用于说明通信，不涉及文件或网络。输出哪一个 Index 在前由调度决定，没有按输入顺序输出的承诺。本文未执行代码，后面的观察点也不是已经通过的测试结果。

这个结构换来了什么，又没有保证什么

我不会承诺“cancel 发生后绝对不再发送一个值”。select 中若通信与取消同时就绪，可能选择任一可进行的分支。这个示例保证的是存在退出路径、在有限输入和有限计算的前提下可以结束，而不是取消时刻的严格数据切割。若业务需要严格截断，应在结果消费或提交层定义额外协议。

Context 也不能强制打断普通阻塞调用。将乘二换成网络请求、锁等待或外部库函数后，必须分别确认那些操作支持取消或有自身期限。若某个工作者始终不返回，WaitGroup 当然不会完成；给等待包上计时器只会停止调用方等待，不会自动终止工作者。

同样，固定工作者不等于整个服务的 goroutine 总数有界。若同时启动无限多批次，每批都有生产者、工作者和协调者，系统仍会膨胀。要扩大使用范围，我会先限制活跃批次数，再看队列长度、取消后停止延迟和 goroutine 堆栈，而不是只调一个 channel 容量。

我会怎样确认没有留下等待者

建议读者先在独立目录尝试正常消费，再尝试提前退出；本文不启动本地程序或并发测试。

# 在保存main.go的独立目录执行，观察停止确认是否到达。
go run main.go

正常完整消费时，四个输入应各产生一条对应结果，但顺序不固定。按示例只接收第一条后取消时，不要求收齐四条，重点是 stopped 能否关闭。空输入时，不应等一个永远不存在的结果；已取消的 Context 则应允许参与者观察取消后退出。

如果程序仍卡住，我会查看实际等待语句：卡在接收说明缺值或关闭通知，卡在发送说明接收端没有继续服务，卡在 Wait 则说明至少一个受管理任务尚未 Done。日志中的“准备退出”不能代替已经返回，也不要通过 recover 掩盖向已关闭通道发送的设计错误。

每个 goroutine 都 defer close(out) 可以吗？

多个发送者共享 out 时不可以随意这样做，重复关闭和发送到已关闭通道都可能恐慌。只有能确认所有发送已结束的拥有者才应关闭它。

所有 channel 都必须关闭吗？

不必须。close 是“不会再发送”的通信信号，不是通用释放内存操作。若接收方使用 range 等待结束，需要明确谁发出这个信号；只靠垃圾回收不会唤醒等待者。

缓冲大小设成任务数能解决吗？

在任务数有限、每项发送次数明确的特定方案里，它可以避免某些发送等待，但没有自动解决取消、生产者阻塞、未知任务规模和关闭归属。本文选择显式退出协议，是因为这些边界更容易被调用方看到。

我的结论是：把 goroutine 返回、channel 关闭、Context 取消和停止确认看成四件事。只有它们之间的责任明确，才不会出现“这一端已经退出，另一端却还在等”的错觉。

参考：Go 通道接收规范、CancelFunc、WaitGroup。示例架构与观察计划为原创设计。