channel 生命周期

channel 的生命周期关键不在于“谁能拿到它”，而在于“谁能证明以后不会再发送”。Go 规定，向已经关闭的 channel 发送会触发运行时 panic；关闭本身也只能表达“后面不再有值”。因此，稳定的做法是让发送方或发送方协调者成为唯一的 close owner，接收方只负责消费和判断结束，不用 recover 掩盖关闭协议错误。

关闭后的 channel 到底发生了什么

close(ch) 记录的是“不会再有新值发送”。缓冲 channel 中已经成功发送的值仍可被接收；这些值消费完后，接收操作会立即得到元素类型的零值，双返回值中的 ok 为 false。相反，发送操作没有“失败返回值”这一层缓冲：只要目标已经关闭，就直接 panic。

func drain(ch 

这也是为什么“发送前先检查 channel 是否关闭”不是可靠修复：Go 没有通用的无竞态 isClosed 检查，检查完成后另一个 goroutine 仍可能立即执行 close。问题应回到所有权和退出协议，而不是增加一个猜测状态。

单发送方：让最后一次发送和 close 连在一起

只有一个生产者时，最简单的生命周期是：生产者创建并发送，发送循环结束后由它关闭；消费者只读。这里的“结束”必须是生产者自己的确定条件，例如输入遍历完或上游返回错误。

func produce(out chan

这个结构有一个很实用的核对点：调用方只需要找到“最后一个可能执行发送的 goroutine”，它就是 close owner。不要让消费者为了结束 range 去关闭 in，否则消费者和生产者之间会出现竞态。

多个发送方：先停发送，再关闭数据 channel

多个生产者时，任何一个生产者都不能仅凭“我结束了”就关闭共享 channel，因为其他生产者可能仍在发送。协调者应把关闭拆成两个阶段：先广播停止信号，让发送循环不再产生新值；再等待所有发送方退出；最后由协调者关闭数据 channel。

func fanIn(values []int, workers int) 

示例中 done 的关闭动作应由更上层的取消逻辑负责，并且要保证只关闭一次；若只是自然发送完毕，则等待组归零后直接关闭 out 即可。生产代码还应给每个发送方明确的取消路径，避免发送方卡在下游无人接收的位置。

用四个问题检查生命周期

相关问题

关闭 channel 后还能读到数据吗？

能。已成功发送但尚未取出的值仍会按顺序返回；读完后再通过 ok=false 或 range 结束。

能不能用 recover 防止发送 panic？

不建议。recover 只能截住结果，不能修复谁拥有关闭权、谁负责退出的协议。

为什么多发送方不能各自 defer close？

因为第一个退出的发送方可能早于其他发送方，后续发送就会撞上已关闭 channel；应由协调者在等待全部发送方退出后统一关闭。