go中select+chan实现fan-in易卡死，因未关闭channel或发送goroutine未退出；须由主goroutine在wg.wait()后close，用context控制超时，避免无缓冲chan和消费滞后。
Go 里用 select + chan 做 Fan-In 为什么容易卡死
因为没关 channel，或多个 goroutine 向同一个 chan 发送后没退出，接收方永远等不到 close。Fan-In 的本质是“多发一收”，但 Go 的 channel 不会自动感知发送端结束——你得自己关，且只能关一次。
常见错误现象：fatal error: all goroutines are asleep - deadlock；或者程序跑着不动，range 卡在最后一条数据之后。
- 所有发送 goroutine 必须在发完后调用
close(ch)（不是close接收 channel） - 接收端用
for range ch，它只在ch被关闭后自然退出 - 如果发送端可能 panic 或提前 return，用
defer close(ch)更安全 - 别用无缓冲 channel 做 Fan-In 输入，否则第一个 sender 就会阻塞，直到有人接收——这违背并发本意
sync.WaitGroup 和 close 的协作顺序不能错
WaitGroup 用来等所有 sender 完成，但它和 close 的位置稍有偏差，就会导致 race 或提前关闭。
典型错误：在 goroutine 里 wg.Done() 后立刻 close(ch)，但此时其他 goroutine 可能还没发完，channel 就被关了，后续发送 panic：send on closed channel。
立即学习“go语言免费学习笔记（深入）”；
- 必须等所有 sender 全部返回后，再由主 goroutine 调用
close(out) -
wg.Wait()是同步阻塞点，放在所有 goroutine 启动之后、close()之前 - 不要在 sender goroutine 里 close，哪怕加了 wg —— 因为 wg.Done() 和 close() 之间没有原子性
用 context.Context 控制 Fan-In 超时或取消
真实场景中，某一路数据源可能卡住、慢或永远不返回，这时靠 select + time.After 硬写 timeout 很难维护；用 context 更清晰。
使用场景：聚合日志、多服务 API 结果、MQ 多分区消费合并。
- 每个 sender goroutine 接收
ctx，并在select中监听ctx.Done() - 主 goroutine 调用
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - sender 中若检测到
ctx.Err() != nil，应清理资源并 return，**不往 out channel 发数据** - 接收端仍用
for range out，但需注意：context 取消后，未关闭的 out channel 会一直空转等待——所以务必在wg.Wait()后 close
性能陷阱：别让 Fan-In 成为瓶颈
看似只是“把几个 channel 合成一个”，但如果 sender 数量多、单条数据小、或接收端处理慢，Fan-In 本身会成为吞吐瓶颈。
影响点：channel 的锁竞争、内存分配频次、GC 压力。
- 避免高频小数据：把多个值打包成 slice 再 send，减少 channel 操作次数
- 用带缓冲的 channel（如
make(chan int, 64)），缓冲大小根据平均 burst 量设，太小易阻塞，太大吃内存 - 如果接收端处理耗时，考虑在 Fan-In 后接 worker pool，而不是让所有 sender 直接挤在同一个
range上 - Go 1.21+ 的
chan实现对多生产者更友好，但别依赖——逻辑上仍要保证 close 时机唯一
最常被忽略的是：Fan-In 后的 channel 如果没人及时消费，所有 sender 最终都会被阻塞（即使用了缓冲）。它不是“背锅侠”，而是整个流水线里的承压点——得从端到端看压力在哪，而不是只盯合并逻辑。
