Go中fanOut非标准库函数，须手动实现；关键在于channel关闭责任、缓冲策略及数据分发方式（广播或轮询），而非goroutine数量；直接go worker(inCh)易因未缓冲inCh导致部分worker永久阻塞于range引发死锁。
Go 里的 fanOut 不是标准库函数，也没有“开箱即用”的分发逻辑——它必须手动实现，且关键不在起多少 goroutine，而在谁关 channel、怎么缓冲、要不要复制数据。
为什么直接 for i := 0; i
多个 goroutine 共享一个未缓冲的 inCh，读取行为不可预测：某个 worker 可能把所有值读完，其余卡在 range inCh 等不到新值；更危险的是，如果上游没关 inCh，所有 worker 都永久阻塞在接收端，触发 fatal error: all goroutines are asleep - deadlock。
- 根本问题不是并发多，而是缺乏中心分发者和关闭协调
-
range inCh依赖 channel 关闭才能退出，但没人负责关它 - worker 之间竞争读取，导致数据分配不均甚至丢失
- 无缓冲 channel 下，一旦某个 worker 处理慢，整个输入流就卡住
fanOut 必须用一个 goroutine 控制分发，不能让 worker 直接 range
正确结构是：一个分发 goroutine 从 in 读，再把每个值发给多个目标 channel（广播）或选一个（轮询）。这个 goroutine 还要负责在 in 关闭后，显式关闭所有 out channel。
- 每个
out[i]必须带缓冲，例如make(chan T, 1)，否则快 worker 会因慢 worker 未消费而阻塞发送端 - 分发 goroutine 内部要用
for v := range in，而不是select—— 否则可能漏掉关闭信号 - 关闭所有
out必须放在defer或循环结束后，且要在in被完全读完之后 - 不要在 worker 里调用
close(in)或close(out)，这会破坏扇入聚合逻辑
广播式 fanOut（每个 worker 收到全部数据）怎么写
适用于事件通知、日志复制等场景，不是任务分片。典型实现中，分发 goroutine 把每个输入值发给所有 out channel：
func fanOutBroadcast[T any](in
- 缓冲大小至少为 1，防瞬间积压导致分发 goroutine 阻塞
- 如果某个
out永远没人读（比如 worker panic 退出），该ch 会永久阻塞整个分发流程 - 真实场景建议加
context.Context控制生命周期，避免单个慢 consumer 拖垮全局 - 别用
select+default来“跳过”写失败 —— 数据会静默丢弃
fanIn 聚合结果时为什么不能直接 for range 每个 input channel
直接遍历会漏数据：一旦某个 input channel 关闭，range 就退出，其他还没读完的 channel 就被跳过了。标准解法是为每个 input channel 启一个 goroutine，统一往一个 out 写，再用 sync.WaitGroup 等全部写完后关闭 out。
- 每个转发 goroutine 必须用
for v := range c，并配合wg.Done() -
out建议设为带缓冲 channel（如make(chan T, numWorkers*2)），避免 worker 因接收端未就绪而挂住 - 如果某个 input channel 永不关闭（比如持续推送日志），
fanIn就永远不会结束；此时需配合context.WithTimeout主动中断对应 goroutine - 别在主 goroutine 里一收到第一个 job 就
close(out)，这是常见错误，会导致后续写入 panic：send on closed channel
最易被忽略的点是：fanOut/fanIn 的安全边界不在 goroutine 数量，而在 channel 关闭时机与缓冲容量的匹配。一个没缓冲的 out + 一个永远不消费的 worker，就能让整个 pipeline 卡死；而一个过大的缓冲，又会让背压失效，最终 OOM。实际部署前，务必用 len(ch) 和 cap(ch) 监控通道积压情况。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
