fan-out需由单一goroutine分发并显式关闭输入channel，否则多worker共享未缓冲inch会导致部分goroutine永久阻塞在range上引发死锁。
fanOut 不是标准库函数，也没有“开箱即用”的分发逻辑——它必须手动实现，且关键在于谁负责关闭输出 channel、是否缓冲、是否广播或轮询。
fanOut 分发时为什么直接 go worker(inCh) 会死锁
- 多个 goroutine 共享一个未缓冲的
inCh，读取行为不可预测：可能某个 worker 把所有数据读完，其余卡在range inCh等不到新值，但又没人关 channel - 更危险的是：如果上游没关
inCh，所有 worker 都永久阻塞在接收端，触发fatal error: all goroutines are asleep - deadlock - 正确做法是由一个分发 goroutine 控制流向，避免竞争，也便于统一关闭
常见错误写法：
for i := 0; i <p>正确结构要点：</p>
- 用一个 goroutine 从
inCh读，再把每个值发给多个目标 channel（广播）或选一个（负载均衡） - 每个目标 channel 必须带缓冲（如
make(chan int, 10)），否则快 worker 可能因慢 worker 未消费而阻塞发送端 - 输入 channel 关闭后，分发 goroutine 必须显式关闭所有输出 channel
如何实现广播式扇出（每个 worker 收到全部数据）
适用于事件通知、日志复制等场景，不是任务分片。
典型实现：
func fanOutBroadcast[T any](in go func() {
defer func() {
for _, ch := range outs {
close(ch)
}
}()
for v := range in {
for _, ch := range outs {
ch <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0"><img
src="https://img.php.cn/upload/manual/001/589/237/6a6adeed24a4a355.png" alt="Go语言（Golang）1.26.0" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="overflowclass">Go语言（Golang）1.26.0</a>
<p class="overflowclass">Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
注意点：
- 不要用无缓冲 channel 做广播中间层，否则任意一个
ch 阻塞，整个分发就卡住 - 如果某 worker 消费极慢，它的 channel 缓冲会满，后续广播将阻塞——这是设计使然，不是 bug；若需削峰，得加背压控制（如
select+default丢弃） - 返回的
[]chan T是只接收类型，调用方不能往里 send，避免误用
如何实现负载均衡式扇出（每个任务只发给一个 worker）
适用于 HTTP 请求、数据库查询等耗时不均的任务分发。
核心是让任务主动挑 channel，而不是固定轮询：
workers := make([]chan Task, 3)
for i := range workers {
workers[i] = make(chan Task, 10)
}
<p>// 分发 goroutine
go func() {
defer close(taskCh) // 假设 taskCh 是输入源
for task := range inputTasks {
idx := rand.Intn(len(workers)) // 随机选，不锁
select {
case workers[idx] </p>
关键差异：
-
rand.Intn比i % len(workers)更适应真实响应时间方差 - 每个
workers[i]必须有足够缓冲（比如 10），否则随机写入容易失败 - 不要依赖
len(workers)动态变化；若需扩缩容，得用sync.RWMutex保护切片读写，但会增加复杂度
扇出最难的部分不是写 goroutine，而是决定数据怎么走、谁关 channel、缓冲设多大、超时怎么介入。这些决策一旦定错，泄漏和死锁就藏在上线后的凌晨三点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
