扇出模式下避免 goroutine 泄漏的关键是让每个 goroutine 对上下文生命周期敏感：所有通道操作必须用 select 包裹 send/recv 和 ctx.done()；输入通道需明确关闭边界；避免无缓冲通道用于中间层，缓冲大小须匹配并发数。
扇出模式下如何避免 goroutine 泄漏
扇出的核心是启动多个 goroutine 并发处理任务，但若上游提前退出（比如超时或取消），没被消费的下游 goroutine 很容易持续阻塞在 send 或 recv 上，最终堆积泄漏。
关键不是“多开几个”，而是让每个 goroutine 都对上下文生命周期敏感：
- 所有通道操作必须配合
ctx.Done()使用，用select包裹send/recv+ctx.Done() - 扇出前确保输入通道已关闭或有明确边界，不要依赖“对方会关”——谁创建、谁负责通知结束
- 避免无缓冲通道用于扇出中间层；缓冲通道大小需与并发数匹配，否则写入端可能永久阻塞
示例：错误写法是 go worker(inCh) 直接启动；正确写法是 go worker(ctx, inCh, outCh)，并在 worker 内部用 select { case 。
负载不均时，为什么 round-robin 分发不如随机选 worker
Go 的调度器不保证 goroutine 执行时间片均等，尤其当 worker 处理逻辑含 I/O 或不定长计算时，固定轮询（round-robin）会让慢 worker 持续积压任务，快 worker 闲置。
立即学习“go语言免费学习笔记（深入）”；
更实用的做法是让每个任务主动“挑人”：
- 把 worker 的输入通道存进切片（
[]chan Task），每次从切片中随机取一个通道发送，用rand.Intn(len(workers)) - 不用锁，因为只读切片 + 通道本身线程安全；注意切片不能动态增删，否则需加读锁
- 如果 worker 数量固定且已知，可预分配数组，避免切片扩容带来的偶然竞争
对比：轮询在 CPU 密集且耗时稳定时有效；随机分发在真实业务中（HTTP 请求、DB 查询等）响应时间方差大，效果更稳。
扇出后结果聚合阶段 panic: send on closed channel 怎么防
这是扇出最常踩的坑：多个 worker 向同一个结果通道写入，主协程在收到足够结果后关闭通道，但仍有 worker 在写——send on closed channel 立刻 panic。
- 绝不让多个 goroutine 直接往同一无缓冲通道写；要么用带缓冲通道（容量 ≥ 最大可能存活 worker 数），要么用
sync.WaitGroup+ 单独收集 goroutine - 推荐方式：每个 worker 写自己的
chan Result，主协程用select轮询所有结果通道（可用for range配合reflect.Select动态处理，但小规模直接列case更清晰） - 如果必须共用通道，改用
errgroup.Group，它自动等待所有 worker 结束后再关闭结果通道
注意：close(ch) 只应由唯一确定的协程调用，通常是主协程在确认所有 worker 已退出后执行。
用 time.After() 做扇出超时控制为何有时不生效
time.After() 返回的通道在超时前不会触发，但它本身不取消正在运行的 worker。也就是说，超时到了，主协程退出，但 worker 还在跑、还在发结果、甚至还在占资源。
- 必须把
context.WithTimeout()传给每个 worker，worker 内部用ctx.Done()判断是否该中止当前任务 -
time.After()适合做“等结果最多 X 秒”，但不适合做“中断进行中的工作”——后者必须靠context - 如果 worker 内部有阻塞系统调用（如
http.Client.Do），记得用ctx构造带超时的 client，否则ctx.Done()不会中断底层 socket 等待
真正可靠的扇出超时 = context.WithTimeout 控制生命周期 + 每个 worker 主动检查 ctx.Err() + 主协程不依赖通道关闭来判断完成。
