Go channel关闭责任按生产者划分的工程规则

Go channel 的关闭责任最好跟随“谁还会发送、谁拥有生命周期”来划分，而不是简单交给接收方。单生产者场景由生产者在发送完成后关闭；多生产者场景由协调者等待所有生产者退出，再执行唯一一次 close。接收方只负责读取和判断结束，不直接关闭仍可能被发送的通道。

先按数据流确定 channel 的关闭者

判断关闭者时先问两个问题：还有哪些 goroutine 可能执行发送，以及谁能判断“后续不会再有数据”。只要接收方无法证明所有发送者都退出，就不能由接收方调用 close。因为关闭后的发送会触发运行时 panic，多个位置重复关闭也会触发 panic。

可以把责任写成一条工程规则：唯一发送者负责关闭；多个发送者把关闭权交给等待它们结束的协调者；纯停止通知使用独立的 done 或 context.Context，不要把数据通道同时当作取消开关。

单生产者用 defer 固化关闭时机

只有一个生产者时，最稳妥的写法是在生产函数内部关闭。把 close(out) 放在函数退出路径上，可以覆盖正常完成和中途返回；接收方使用 range，收到关闭信号后自然退出。

func numbers(done 

这里的关键不是 defer 本身，而是发送方向被限制为 chan。接收方拿不到关闭权限，接口边界也会提醒维护者：它只能消费数据。

多生产者用协调者统一执行 close

多个 worker 共同向一个 channel 发送时，任何一个 worker 都无法单独判断其他 worker 是否已经结束。可以让每个 worker 只负责发送和返回，另起一个协调 goroutine 等待计数归零后关闭通道。

import "sync"

func merge(done 

调用方只需消费返回的只读通道。生产者的正常完成、提前取消和空任务都能汇聚到同一个 Wait 路径，避免“某个 worker 先 close，另一个 worker 仍在 send”的竞态。

把停止信号与数据通道分开

关闭数据 channel 表示“不会再有数据”，而 done 或 context 表示“请停止工作”。两者语义不同。取消时，生产者从 select 的停止分支返回，协调者观察到所有生产者完成后再关闭数据通道；接收方仍然只处理数据通道的结束。

如果接收方提前退出，生产者可能卡在发送操作上。此时必须让发送同时监听停止信号，或者保证接收方继续排空数据。只关闭 out 并不能唤醒一个已经阻塞在发送端的 goroutine。

用检查清单排除关闭竞态

代码审查时重点搜索 close(、所有发送表达式和 goroutine 的返回路径，再对应到同一张生命周期图。若关闭者无法回答“最后一个发送者何时退出”，说明责任边界还没有落地。

常见问题

接收方知道数据已经够了，能直接关闭 channel 吗？

通常不能。接收方可以发取消信号，让生产者停止；等生产者全部退出后，再由既定协调者关闭数据 channel。

关闭 channel 后还能读取剩余数据吗？

可以。关闭只禁止后续发送，接收方仍能读出缓冲区中的剩余值，读完后 range 才结束。

用一个布尔变量记录是否关闭是否更安全？

不够安全。检查和发送之间仍可能发生竞态，而且多个关闭者还会重复关闭。更可靠的做法是收拢关闭权，并用 WaitGroup 或 context 明确生命周期。