Go语言中Channel行为困惑：接收者多于发送者时为何表现不同？

核心差异就一句话：两段代码里的Channel在发送完成后是否被关闭，这直接决定了接收操作的行为。

第一段代码（无限阻塞）的逻辑 #

• 4个goroutine各自发送一次数据后就退出了，但没人去关闭Channel。
• 主函数前4次接收能正常拿到goroutine发的数据，但第5次接收时，Channel是空的，而且还没被关闭。
• 在Go的规则里，对「未关闭的空Channel」执行接收操作，当前goroutine会被死死卡住——因为Go会默认还会有新的发送者过来传数据，所以主goroutine就无限阻塞在那了。

第二段代码（触发预期错误）的逻辑 #

• 2个goroutine发完数据后，主动关闭了Channel。
• 主函数前2次接收正常拿到数据，第3次接收时，Channel已经关闭且空了。
• 这时接收操作会立刻返回「对应类型的零值 + false」（第二个返回值ok表示是否还有有效数据）。如果你的代码里做了判断——比如ok为false时就抛出错误（比如用log.Fatal或者手动panic），那就会触发你说的“预期错误”。
• 补充：如果是用for range遍历Channel，关闭且空的Channel会让循环自动退出；但手动多次接收的话，就得自己处理ok值，不然拿到零值可能会引发业务逻辑问题。

关键规则梳理 #

• 未关闭的空Channel：接收→阻塞，直到有数据或Channel被关闭。
• 已关闭的空Channel：接收→立即返回零值+false，不会阻塞，也不会原生panic（错误是代码逻辑里手动触发的）。

内容的提问来源于stack exchange，提问作者Zenitsu Komodo