本文详解 go 中 fan-in 模式下通道未关闭导致死锁的问题，通过 sync.waitgroup 实现多 goroutine 协同完成后的通道自动关闭，确保 range 遍历安全终止。
本文详解 go 中 fan-in 模式下通道未关闭导致死锁的问题，通过 sync.waitgroup 实现多 goroutine 协同完成后的通道自动关闭，确保 range 遍历安全终止。
在 Go 并发编程中，fan-in 是一种常见模式：将多个输入通道（如来自不同数据源的 <-chan int）合并为一个统一输出通道，供下游消费。但若不显式关闭该合并通道，for v := range out 将永久阻塞——因为 Go 的 range 语义要求通道被显式关闭后才退出循环。原代码中 fanIn 函数创建了 out 通道却从未关闭它，而各子 goroutine 在读取完各自输入通道后悄然退出，主 goroutine 却因等待永远不会到来的“关闭信号”而死锁。
正确解法：WaitGroup + 协程关闭通道
核心思路是：追踪所有并发读取 goroutine 的完成状态，并在全部结束后关闭输出通道。sync.WaitGroup 是为此类场景量身定制的同步原语：
import "sync"
func fanIn(in ...<-chan int) <-chan int {
var wg sync.WaitGroup
out := make(chan int, 10) // 缓冲通道避免发送阻塞
// 启动每个输入通道的读取 goroutine
for _, ch := range in {
wg.Add(1)
go func(ch <-chan int) {
defer wg.Done() // 标记当前 goroutine 完成
for val := range ch {
out <- val // 直接发送，无需额外 goroutine（避免竞态与资源浪费）
}
}(ch)
}
// 启动独立 goroutine 等待所有读取完成并关闭通道
go func() {
wg.Wait()
close(out) // 关键：所有输入耗尽后关闭输出通道
}()
return out
}✅ 关键改进点说明：
- 移除嵌套 goroutine：原代码中 go func(c int) { out <- c }(val) 为每个值启动新 goroutine，不仅无必要，还可能因缓冲区满或调度延迟引发不可预测行为；直接 out <- val 更高效、更可控。
- WaitGroup 精准计数：wg.Add(1) 在启动前调用，defer wg.Done() 在 goroutine 结束时执行，确保计数准确。
- 关闭时机可靠：wg.Wait() 阻塞至所有读取 goroutine 返回（即所有输入通道被读空），此时关闭 out 是安全且唯一的正确时机。
注意事项与最佳实践
- 永远不要在多个 goroutine 中重复关闭同一通道：close() 只能调用一次，多次调用 panic。本方案由单一 goroutine 执行 close(out)，杜绝风险。
- 缓冲区大小需权衡：示例中 make(chan int, 10) 提供基础缓冲，防止生产者过快阻塞；实际应根据数据量和内存约束调整，或考虑无缓冲通道配合 select 处理背压。
- 错误处理扩展性：若输入通道可能因错误提前关闭（如网络中断），应在 for range ch 循环内检查 val, ok := <-ch，并在 !ok 时及时 wg.Done()。
- 替代方案考量：对于更复杂的流控或需要取消的场景，可结合 context.Context 与 errgroup.Group（它内部封装了 WaitGroup 和错误传播），但对纯 fan-in 场景，标准库 sync.WaitGroup 已足够简洁高效。
综上，使用 sync.WaitGroup 协同关闭通道是 Go 中处理多 goroutine fan-in 的惯用且健壮的解决方案。它清晰表达了“等待所有输入完成，再关闭输出”的业务逻辑，既符合 Go 的并发哲学，又彻底规避了死锁隐患。
