Go select 怎样同时处理两个输入 channel

如果一个 goroutine 需要等待两个输入来源，Go 的 select 可以把两次接收写在同一个通信选择点里。它的“同时”指同时等待：每次进入 select 时，运行时会在当前可继续的通信中选一个 case；并不是两个 case 同时执行。

最容易出问题的地方通常不是语法，而是收尾：某个输入 channel 关闭后，继续接收会反复得到零值；两个输入都没有数据时，如果误加了 default，循环又可能变成空转。

官方资料：https://go.dev/tour/concurrency/5

一句话做法：为两个输入分别写 case value, ok := ，用 ok 判断关闭状态，关闭后把对应 channel 变量设为 nil；两路都结束后再关闭统一输出。

影响面：两个输入没有被及时汇总

假设一个服务同时接收“订单事件”和“库存事件”。如果把两个输入拆成两段互相阻塞的代码，就可能先等订单，库存已经有消息也没人处理；反过来也一样。把两路接收放进同一个 select，可以让一个 goroutine 观察两个来源，哪个通信此刻能继续，就处理哪个。

这里的目标是“一个等待点管理两路输入”，不是人为给某个 channel 排优先级。两个 case 都可接收时，不能依赖源码中谁写在前面；如果业务真的有优先级，应在数据模型或调度策略中显式表达。

时间线：先写两个接收 case，再观察关闭状态

最小结构只有两个接收分支。每轮循环重新进入 select，两个输入都可以成为候选通信。

for {
	select {
	case order := 

这段写法适合两个 channel 都会长期存活的场景。实际工程中还要处理关闭，否则某一路关闭后，接收表达式会不断拿到该类型的零值，业务层就可能把“输入结束”误认为一条空事件。

触发条件：value 和 ok 必须一起判断

接收 channel 时，可以同时拿到值和布尔状态：ok == true 表示这次接收拿到了一个有效发送值；ok == false 表示 channel 已关闭且没有更多值。不要只看 value，因为零值本身可能就是合法业务数据。

for orders != nil || stocks != nil {
	select {
	case order, ok := 

把已关闭的变量设为 nil 是关键动作。规范规定 nil channel 上的通信永远不能继续，因此对应的 case 会从后续选择中退出；循环仍可等待另一条输入。循环条件也要允许两路都变成 nil 后自然结束。

根因：关闭 channel 后的零值会制造假消息

下面这类写法看起来简洁，但没有关闭判断：

for {
	select {
	case order := 

问题的根因是把“收到一个值”和“输入仍然开放”当成了同一件事。接收语法允许返回两个结果，应该利用第二个结果表达生命周期。对于字符串、整数、结构体等类型，零值都有可能是合法数据，不能靠值内容猜测 channel 是否关闭。

修复动作：把两路输入封装成一个输出

如果下游只想处理一条事件流，可以把两路只读 channel 汇总成一个输出 channel。汇总函数只负责通信边界，订单和库存的业务解释仍由调用方负责。

func fanIn(orders, stocks 

这个实现有三个收尾点：输入参数使用只读方向，避免汇总函数反向发送；关闭的输入设为 nil；两路都关闭后由 defer close(out) 通知下游结束。下游只需要继续读取返回值，直到输出 channel 关闭。

防复发：default 不是“没有消息就跳过”的免费选项

没有 default 时，如果两个接收都暂时不能继续，select 会阻塞，适合等待事件的消费者。加上 default 后，两个输入都没有数据时会立即进入默认分支：

select {
	case order, ok := 

如果把这段代码放进没有节奏控制的无限循环，default 会让循环持续空转，占用 CPU。需要持续观察时，优先让 select 阻塞；确实要轮询时，再配合明确的等待节奏，并把关闭状态和退出条件写清楚。

一份发布前的复查清单

1. 两个输入是否都写成了独立的接收 case？
2. 是否使用 value, ok 区分有效值与关闭状态？
3. 关闭后是否把对应 channel 设为 nil，避免反复被选中？
4. 两路都结束后，统一输出 channel 是否只关闭一次？
5. 是否误以为 case 顺序提供优先级，或误把 select 当成两个分支同时执行？
6. 是否真的需要 default，以及它会不会让循环空转？

相关问题

两个 channel 同时有数据时一定先处理第一个 case 吗？ 不一定。可继续的通信不止一个时，不能依赖源码顺序作为优先级。

为什么关闭 channel 后要赋值为 nil？ 因为 nil channel 永远不能完成通信，这样对应 case 会被停用，而另一条输入仍可继续等待。

两个输入 channel 都关闭后需要手动退出吗？ 汇总函数可以让两个变量都变成 nil，再让循环条件结束，并通过关闭输出 channel 通知下游。

什么时候应该保留 default？ 一次性的非阻塞探测可以使用；持续消费者通常应避免无节奏的 default 循环。

所以，“Go select 怎样同时处理两个输入 channel”的答案不是复制两段接收代码，而是把两路通信放在一个等待点，利用 ok 管理生命周期，再决定是阻塞等待还是明确的非阻塞探测。