Go nil channel 放进 select 后怎样动态关闭一个分支

在循环里用 select 同时监听多个 Go channel 时，某个输入一旦关闭，最容易踩到的坑是：关闭后的 channel 仍然会被不断选中，循环拿到元素类型的零值，CPU 也跟着空转。解决办法不是继续调用 close，而是把 select 使用的那个局部 channel 变量赋为 nil，让这一条 case 失去通信资格。

先把三种 channel 状态分开

可以把排查指标压缩成三个计数：当前仍活跃的输入数、已经收到的有效值数、已经观察到的关闭事件数。它们分别回答“还要监听谁”“业务处理了多少数据”和“哪个分支应该退出”，不要把三个概念混成一个布尔值。

nil channel 为什么能让 select 分支失效

Go 语言规范规定，对 nil channel 发送或接收都不能完成；因此只有 nil channel 的 select、且没有 default 时，会一直阻塞。关键点在于：select 每次进入时都会重新评估各个通信操作使用的 channel 表达式，所以循环中的局部变量可以承担“当前是否还监听这个分支”的开关。

var input 

这里没有关闭接收方持有的 channel，也没有修改发送方的生命周期。input = nil 只改变当前循环下一次 select 看到的通信对象；它适合用来屏蔽一个已经完成的输入分支。

双输入 fan-in 怎样安全退出

两个输入汇聚到一个输出时，两个局部变量都要独立处理。一个输入先关闭，不代表另一个输入也结束；只有当两个变量都成为 nil，循环才应关闭输出并退出。

func fanIn(left, right 

这个循环的可验证结果是：有效值数只在 ok=true 时增加，关闭事件数每个输入最多计一次，活跃输入数从 2 逐步降到 0。最后一个输入置 nil 后，循环条件失败，defer close(out) 负责通知下游结束。

四个容易误用的边界

• 不要写 close(input) 来禁用接收分支。关闭 channel 是发送方或拥有关闭权的一方的生命周期动作；接收方通常只消费关闭信号。
• 不要只判断值是否为零。业务数据本身可能就是零，必须使用双返回值 value, ok := 。
• 不要给这种循环随手加 default。如果没有数据时仍需要等待，default 会把阻塞等待改成忙轮询，除非你明确配合退避或调度策略。
• 不要把共享的 channel 变量在多个 goroutine 中无保护地改成 nil。本例把状态放在单个 fan-in goroutine 内，避免额外的数据竞争。

相关问题

关闭后的 channel 为什么还会被 select 选中？因为关闭接收可以立即完成，并返回零值；只有把对应的局部 channel 变量设为 nil，才会从候选通信集合中移除。

两个输入都为 nil 时会不会死锁？只要循环条件写成 for left != nil || right != nil，最后一个输入置 nil 后循环就结束；如果仍进入没有 default 的 select，才会得到永久阻塞。