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