Go中合并多个数据流需区分场景：无序聚合用Fan-In模式（WaitGroup同步关闭输出channel），有序合并用双指针归并（严格处理关闭信号）；select不适合纯数据聚合，易卡死或漏数据。
Go 里合并多个数据流，核心不是“拼起来就行”，而是得保证正确关闭、不丢数据、不 panic。直接用 select 轮询多个通道会卡死或漏数据；裸写 goroutine + range 又容易因变量捕获出错或提前关 channel。真正能落地的方案只有两种：Fan-In 模式（适合无序聚合）和有序同步合并（如归并排序式交集/并集），选错就掉坑里。
用 Fan-In 模式合并多个无序通道
这是最常见场景：日志收集、监控指标汇总、多协程结果归并。关键不是并发转发，而是等所有输入结束再关输出通道。
- 必须用
sync.WaitGroup计数，不能靠len(channels)减一——goroutine 间读写非原子，n -= 1会竞态 - 每个 goroutine 的闭包参数要显式传入，否则
for _, c := range channels { go func() { ... }() }里的c是共享变量，最后全指向最后一个通道 - 输出 channel 缓冲大小建议设为
len(channels)，避免第一个 goroutine 写满后阻塞，其他 goroutine 卡在发送上 - 关闭输出通道的操作必须在独立 goroutine 中做，且只能由它调用
close(out)；如果在某个转发 goroutine 里关，其他 goroutine 往已关 channel 写会 panic
示例片段：
func FanIn(channels ...<-chan int) <-chan int {
out := make(chan int, len(channels))
var wg sync.WaitGroup
wg.Add(len(channels))
for _, ch := range channels {
go func(c <-chan int) {
defer wg.Done()
for v := range c {
out <- v
}
}(ch) // 注意：这里把 ch 显式传进去
}
go func() {
wg.Wait()
close(out)
}()
return out
}合并两个已排序通道（归并式同步）
当输入通道数据本身有序（比如时间戳升序的日志流、索引文件游标），需要保持全局顺序输出，就不能用 Fan-In。必须双指针逐个比较，且严格处理通道关闭信号。
立即学习“go语言免费学习笔记（深入）”；
- 从通道读取时，要用
v, ok := <-ch判断是否关闭，不能只依赖range——range会自动退出，但你可能还要等另一个通道的数据 - 循环条件必须是
okA || okB，而不是!okA && !okB，否则一个通道先关，另一个还有数据时就提前退出 - 每次迭代至少推进一个通道：如果
!okA，就只读B并写入；如果两者都 ok，比较后只读走较小值对应的那个通道 - 别在循环里重复
<-ch——已经ok == false的通道再读会永久阻塞
典型错误写法：av, ak := <-a; bv, bk := <-b; for ak || bk { ... } ——第一次读完就卡死了，后续没机会再读。
避免 select{} 在多路合并中误用
select 本身不是为“合并多个通道到一个输出”设计的，它是事件分发器。强行用它做 Fan-In 会出问题：
- 如果所有输入 channel 都空，
select会阻塞，但你不知道该等谁 —— 它不告诉你哪个 channel 就绪，只随机选一个 - 没法知道“所有输入都结束了”，所以无法安全关输出 channel
- 加
default变成忙轮询，CPU 拉满却啥也不干 - 真要用
select，只适合监听“控制信号+数据通道”的混合场景，比如超时中断、取消信号介入，而不是纯数据聚合
简单说：select 适合“响应式分发”，不适合“聚合式合并”。混用会导致逻辑断裂，调试时连 goroutine 都找不到在哪卡住。
真正难的不是写几行 goroutine，而是判断清楚：数据是否有序？是否需要保序？输入是否会提前关闭？有没有下游消费速度慢导致反压？这些条件一变，合并策略就得换——没有银弹，只有匹配场景的解法。
