close(ch) 不能直接替代通知机制，因为带缓冲通道本身不提供“任务结束”信号；close(ch) 仅表示“不再写入”，而消费者可能仍在读取缓冲区剩余数据，若此时关闭通道，会导致消费者提前退出或 panic（如对已关闭通道调用 ch<-）。
为什么 close(ch) 不能直接替代通知机制
带缓冲通道本身不提供“任务结束”信号，close(ch) 只表示“不再写入”，但消费者可能仍在读取缓冲区剩余数据，此时关闭通道容易导致消费者提前退出或 panic（比如对已关闭通道调用 ch ）。更常见的是：生产者关了通道，消费者却卡在 <code><-ch 上——因为缓冲区已空，而通道又已关闭，<-ch 立即返回零值，若没做 ok 判断，就会把零值当有效数据处理，逻辑出错。
所以必须配合显式通知（如额外的 done 通道或 sync.WaitGroup），让消费者明确知道“所有数据已送达且不会再有新数据”。
用 done 通道配合带缓冲通道的典型写法
核心思路：生产者发完所有数据后，再向 done 发一个信号；消费者先消费缓冲通道，再等待 done 关闭或接收信号，确保不漏数据也不死等。
- 生产者侧：先往带缓冲通道
ch写完所有数据，再close(ch)（可选），最后向done发送一次（或关闭done） - 消费者侧：用
for v, ok := <-ch; ok; v, ok = <-ch消费缓冲区；循环结束后，再<-done或select等待done - 如果
done是chan struct{}，推荐关闭它而非发送，避免多个消费者竞争单次发送
示例片段：
立即学习“go语言免费学习笔记（深入）”；
// 生产者
go func() {
for _, item := range data {
ch <- item // ch 是 make(chan int, 10)
}
close(ch) // 表明数据发完了
close(done) // 通知消费者：可以收工了
}()
<p>// 消费者
for v := range ch { // 自动感知 close(ch)，安全消费全部缓冲数据
process(v)
}
<-done // 等待生产者彻底完成（比如清理、日志等后续动作）
用 sync.WaitGroup 替代 done 通道的适用场景
当生产者不止一个 goroutine，或者需要精确计数“所有生产者都完成了”，sync.WaitGroup 比 done 更可靠。它不依赖 channel 的通信时序，避免因关闭过早或过晚引发竞态。
-
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 <- v: ... case <-time.After(5 * time.Second): return }避免无限阻塞
真正防泄露的关键不在“有没有缓冲”，而在“谁负责决定何时停止写、谁负责确认读完、以及两者如何同步”。通道只是管道，协调逻辑得靠显式信号或计数。
