Go语言select与多协程接收不同通道的逻辑性能差异及扇入实现疑问

我们从逻辑和性能两个维度对比：

逻辑差异 #

• select方案是单goroutine串行处理所有通道消息：所有消息处理逻辑天然互斥，不需要额外加锁就能操作共享资源；整个接收生命周期统一，所有通道关闭后即可直接退出，不需要额外做goroutine同步，你示例中的receive2接收完所有数据就会自动退出，不需要靠main函数里的Sleep兜底，逻辑更严谨。
• 多goroutine方案是多goroutine并发处理各通道消息：不同通道的消息处理是并行的，若处理逻辑涉及共享变量必须加同步锁；要保证所有消息处理完成再退出主逻辑，需要额外引入sync.WaitGroup等组件做同步，你示例中的receive靠Sleep等待的写法在正式项目中完全不可用，很容易出现接收未完成就提前退出的问题。

性能差异 #

• 通道数量较少（一般5个以内）时，select方案性能更高：不需要创建额外goroutine，没有goroutine调度开销，Go runtime对少量case的select优化非常成熟，调度成本极低。
• 通道数量大且是动态变化的场景，多goroutine方案性能更稳定：select的case需要硬编码，且runtime处理select的开销会随着case数量上升线性上涨；而单goroutine监听单通道的模式开销和通道数量线性相关，Go的goroutine本身初始化成本只有2KB，调度开销极低，即使上万量级的通道也能稳定运行。

receive2是不是过度设计？ #

你示例里只有2个固定通道的场景，receive2的写法完全不算过度设计，反而比receive更简洁可靠：没有额外goroutine开销，没有泄漏风险，退出逻辑清晰。
如果是动态的大规模channel数组场景，硬编码select case的写法确实不适用，此时可以用通用的fan-in实现，把多个输入通道的消息统一转发到同一个输出通道处理：

package main

import "sync"

func fanIn[T any](chs ...<-chan T) <-chan T {
    out := make(chan T)
    var wg sync.WaitGroup
    wg.Add(len(chs))
    // 为每个输入通道启动一个goroutine做转发
    for _, ch := range chs {
        go func(c <-chan T) {
            defer wg.Done()
            for v := range c {
                out <- v
            }
        }(ch)
    }
    // 所有输入通道都关闭后关闭输出通道
    go func() {
        wg.Wait()
        close(out)
    }()
    return out
}

主逻辑只需要监听这一个输出通道即可，也可以搭配select同时处理超时、退出信号等其他事件。

为什么select写法是Go的惯用法？ #

核心原因是符合Go的设计哲学：不要通过共享内存来通信，要通过通信来共享内存。

1. select是Go原生支持的channel多路复用语义，处理多IO事件的逻辑非常直观，比如同时处理业务消息通道、超时通道、退出信号通道的场景，select的写法可读性远高于多goroutine加锁同步的写法。
2. 固定少量通道的场景下，select不需要引入额外的goroutine和同步组件，代码复杂度更低，出问题的概率更小。
3. select和动态fan-in的写法是互补关系：固定少量多路复用场景用硬编码select，动态大量通道场景用fan-in转单通道后再用select处理其他事件，二者结合刚好覆盖绝大多数扇入模式的使用场景。

内容的提问来源于stack exchange，提问作者Serge Hulne