close(ch) 不能直接替代通知机制，因为带缓冲通道本身不提供“任务结束”信号；close(ch) 仅表示“不再写入”，而消费者可能仍在读取缓冲区剩余数据，若此时关闭通道，会导致消费者提前退出或 panic（如对已关闭通道调用 ch
为什么 close(ch) 不能直接替代通知机制
带缓冲通道本身不提供“任务结束”信号，close(ch) 只表示“不再写入”，但消费者可能仍在读取缓冲区剩余数据，此时关闭通道容易导致消费者提前退出或 panic（比如对已关闭通道调用 ch ）。更常见的是：生产者关了通道，消费者却卡在 <code> 上——因为缓冲区已空，而通道又已关闭，<code> 立即返回零值，若没做 <code>ok 判断，就会把零值当有效数据处理，逻辑出错。
所以必须配合显式通知（如额外的 done 通道或 sync.WaitGroup），让消费者明确知道“所有数据已送达且不会再有新数据”。
用 done 通道配合带缓冲通道的典型写法
核心思路：生产者发完所有数据后，再向 done 发一个信号；消费者先消费缓冲通道，再等待 done 关闭或接收信号，确保不漏数据也不死等。
- 生产者侧：先往带缓冲通道
ch写完所有数据，再close(ch)（可选），最后向done发送一次（或关闭done） - 消费者侧：用
for v, ok := 消费缓冲区；循环结束后，再 <code> 或 <code>select等待done - 如果
done是chan struct{}，推荐关闭它而非发送，避免多个消费者竞争单次发送
示例片段：
// 生产者
go func() {
for _, item := range data {
ch // 消费者
for v := range ch { // 自动感知 close(ch)，安全消费全部缓冲数据
process(v)
}
<h3>用 <code>sync.WaitGroup</code> 替代 <code>done</code> 通道的适用场景</h3><p>当生产者不止一个 goroutine，或者需要精确计数“所有生产者都完成了”，<code>sync.WaitGroup</code> 比 <code>done</code> 更可靠。它不依赖 channel 的通信时序，避免因关闭过早或过晚引发竞态。</p>
-
WaitGroup的Add()必须在 goroutine 启动前调用，不能放在 goroutine 内部 - 每个生产者 goroutine 结束前必须调用
Done()，且只能调一次 - 消费者调用
wg.Wait()会阻塞，直到所有生产者调用Done()，此时可安全认为缓冲通道已稳定（无新数据写入） - 注意：仍需配合
for range ch消费完缓冲区，wg.Wait()不保证缓冲区为空，只保证“不再写入”
容易被忽略的泄露点：缓冲通道容量与消费者数量不匹配
带缓冲通道不是万能保险。如果缓冲区大小为 N，而消费者只有一个，但生产者一次性写入 N+1 个数据且未控制节奏，第 N+1 个写操作会阻塞——若生产者没被其他逻辑唤醒（比如超时或取消），整个 goroutine 就泄露了。
- 检查
make(chan T, N)的N是否足够承载“峰值突发量”，而不是仅按平均值设 - 消费者不能长期停顿：哪怕用了
range，也要确保它不因外部条件（如网络错误、锁竞争）意外退出，否则缓冲区填满后所有生产者都会卡住 - 考虑加超时：
select { case ch 避免无限阻塞
真正防泄露的关键不在“有没有缓冲”，而在“谁负责决定何时停止写、谁负责确认读完、以及两者如何同步”。通道只是管道，协调逻辑得靠显式信号或计数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
