不能在主goroutine用select轮询多个未关闭channel，因select每次只选一个就绪case，某channel无数据时即阻塞，若其后续关闭又未判ok会导致空转或死锁；正确做法是为每个输入channel启独立goroutine配合for range转发，并用sync.waitgroup等待后关闭输出channel。
直接用 select 轮询多个未关闭的 chan int 会卡死或丢数据，正确做法是每个输入 channel 启一个 goroutine + for range 转发，再用 sync.WaitGroup 控制输出 channel 关闭时机。
为什么不能在主 goroutine 里用 select 合并多个 channel
常见错误现象：fatal error: all goroutines are asleep - deadlock，或部分数据永远没被读到就退出。这是因为 select 每次只选一个就绪 case，一旦某个 channel 暂时无数据，整个循环就阻塞；若该 channel 后续关闭但没做 ok 判断，select 还可能反复“选中”它导致空转。
-
select是竞争式调度，不保证顺序、不感知关闭、无法判断“是否收完” - 手动维护
nilchannel 列表（如ch1 = nil）虽可行，但逻辑复杂、易出错，尤其在动态增删 source 时不可靠 - 没有生命周期控制，goroutine 泄漏风险高——比如某个 source channel 永远不关，转发 goroutine 就永远挂着
标准 fan-in 实现：goroutine + for range + WaitGroup
这是最稳妥、可读性高、能处理任意数量 channel 的方式。核心是让每个 source channel 在自己的 goroutine 中完成「读完即退」，再用 sync.WaitGroup 等待全部结束，最后关闭输出 channel。
- 每个输入 channel 必须传参进 goroutine，避免闭包捕获循环变量（经典陷阱）：
go func(c -
for v := range c自动在 source channel 关闭时退出，无需额外判断ok -
out通道建议设缓冲：make(chan int, 1024)，防止下游消费慢导致转发 goroutine 阻塞 - 关闭
out的时机必须是所有转发 goroutine 全部退出后，由独立 goroutine 调用close(out)
func fanIn(chs []<h3>分布式日志等持续流场景怎么处理关闭逻辑</h3><p>WaitGroup 不适合日志聚合这类长期运行、source 动态上下线的场景。等“所有 goroutine 结束”意味着系统停机，而实际中节点随时可能断连、重启、扩容。</p>
- 聚合 channel 不应依赖 source 是否关闭，而应由外部信号（如
context.Context）控制整体生命周期 - 单个 source goroutine 出错（如网络中断）应记录错误后自行退出，不影响其他源
- 主 goroutine 收数据时用
for v := range out，而不是for { select { ... } }，避免重复检查关闭状态 - 若需优雅 shutdown，应在收到信号后先取消 context，再等待所有 source goroutine 退出（可用带超时的
WaitGroup.Wait()），最后 closeout
容易被忽略的细节：缓冲、recover、context 传递
生产环境最容易栽在这三处。
- 没设缓冲的
out通道，只要一个 worker 写入后下游没及时读，所有转发 goroutine 就全卡住——不是死锁，但吞吐归零 - worker 内部没
recover，某个 panic 会让整个 fan-in 流程崩溃；应包裹为defer func(){ if r := recover(); r != nil { log.Printf("panic in fan-in worker: %v", r) } }() - 裸写 goroutine 不传
ctx，k8s pod 重建时旧进程残留，goroutine 就堆积泄漏；所有阻塞操作（HTTP、DB、time.Sleep）都要配合ctx.Done()
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
