多生产者往同一channel发结果时，消费者提前退出会导致剩余生产者向已关闭channel发送数据而panic；若仅用for range ch，则因无法感知所有生产者是否完成，可能提前结束或永久阻塞。
多生产者往同一 channel 发结果，为什么消费者提前退出或 panic
因为多个 goroutine 同时 close(ch) 会触发 panic: close of closed channel；而只靠 for range ch 退出，又无法保证所有生产者已发完——某生产者卡在发送前就崩溃，或缓冲区还有残留数据，range 就可能提前结束或永远阻塞。
- 无缓冲 channel：发送即阻塞，必须有接收方在等；一旦某生产者没等到接收方就退出，
ch 永久阻塞，整个流程卡死 - 有缓冲 channel：缓冲区满时发送阻塞，但不解决“谁来关、何时关”的协调问题
- 消费者用
for range ch的退出条件是“通道关闭且缓冲/队列为空”，不是“所有生产者执行完毕”
WaitGroup + channel 关闭才是多生产者归并的稳态模式
核心逻辑是让主 goroutine 扮演唯一协调者：它不发数据、不收数据，只计数、等齐、关通道。这样关通道动作是单点、终局、不可重入的。
-
var wg sync.WaitGroup在主 goroutine 初始化，wg.Add(n)声明要等 n 个生产者 - 每个生产者 goroutine 结束前调用
wg.Done()，不碰close() - 主 goroutine 启动一个匿名 goroutine 执行
wg.Wait(); close(results)，避免阻塞主线程 - 消费者放心用
for r := range results，因为关闭信号来自单一可信源头
示例关键片段：
results := make(chan Result, 100)
var wg sync.WaitGroup
<p>for i := 0; i </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><p>go func() {
wg.Wait()
close(results)
}()</p><p>for r := range results {
handle(r)
}</p>
缓冲大小选 0 还是正数？取决于你想要阻塞点在哪
缓冲大小不是性能开关，而是显式声明“允许积压多少未处理结果”。它改变的是阻塞发生的时机，不是吞吐上限。
-
make(chan T, 0)（无缓冲）：每次ch 都阻塞，直到消费者执行 <code>；适合强顺序、低延迟、任务粒度大的场景，比如握手信号 -
make(chan T, N)（有缓冲）：最多缓存 N 个结果；生产者不会因消费者瞬时卡顿而停摆，但若消费者长期慢于生产者，缓冲区满后仍会阻塞；N=1 是常见折中，能吸收一次抖动 - 别盲目设大缓冲：内存占用线性增长，且掩盖了消费者性能瓶颈；真正瓶颈不在通道容量，而在处理逻辑本身
为什么不能用 context 或 select 替代 WaitGroup 做归并协调
context.WithTimeout 或 select with time.After 只能做超时兜底，不能替代精确计数。它们解决的是“最多等多久”，不是“是否全到齐”。
- 超时后
context.Done()被关闭，但此时部分生产者可能还在发、部分结果已在通道里、部分消费者还没读完——你既不知道哪些漏了，也无法安全清空通道 -
select配合多个 channel 容易漏信号，尤其当某个分支永远不就绪时，default分支会不断抢占，导致忙等待或跳过有效数据 - WaitGroup 提供的是确定性同步：只有全部
Done()调用完成，Wait()才返回；这是归并逻辑正确性的基石
真正难的不是写对几行代码，而是意识到：channel 关闭不是“生产者的事”，而是“主 goroutine 的责任”；这个权责分离一旦错位，所有后续逻辑都会漂移。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
