因为将生产与消费逻辑混在同一循环或 goroutine 中，违背 channel 解耦本质：生产者应只负责发任务，消费者只负责收任务；混写导致职责不清、无法独立扩缩容、难以控制生命周期，且易引发死锁或 goroutine 泄漏。
为什么直接用 channel 无法实现真正的生产者消费者解耦
很多人写 goroutine + channel 时，把生产逻辑和消费逻辑塞进同一个 for 循环里，比如：for i := range ch 配合 go func() { ch ，这看似像模型，实则没解决核心问题：生产者不能因消费者处理慢而阻塞自身节奏，消费者也不能因无数据就退出或忙等。真正解耦需要显式控制生命周期、支持多对多、能响应停止信号。
用带缓冲的 channel + done channel 控制 goroutine 生命周期
关键不是“能不能传数据”，而是“谁决定什么时候停”。必须引入 done 通道来通知所有 goroutine 优雅退出，否则 main 函数提前结束会导致部分 goroutine 被强制终止，数据丢失。
-
ch := make(chan int, 100)—— 缓冲区大小要大于单批次最大产出量，否则生产者会阻塞在ch -
done := make(chan struct{})—— 所有 goroutine 都监听它，收到即退出 - 消费者不能只写
for x := range ch，因为range只在 channel 关闭时退出，而关闭时机难协调；应改用select+done
go func() {
defer close(ch)
for i := 0; i < 100; i++ {
select {
case ch <- i:
case <-done:
return
}
}
}()多个消费者如何公平竞争且不漏数据
如果起多个 goroutine 消费同一个 channel，Go 运行时会自动调度，但要注意：没有“轮询”保证，只是随机唤醒。只要 channel 没关、select 不超时，就不会漏数据；但若消费者内部处理耗时差异大，容易出现某一个 goroutine 吃掉大部分任务。
- 用
for+select循环消费，不要用range（除非你确定 channel 一定会被关闭） - 每个消费者都监听
done，避免主流程退出后还在空转 - 若需负载更均衡，可加简单计数器或使用
sync.WaitGroup等待全部完成，但别在消费循环里做同步操作，会拖慢吞吐
for i := 0; i < 3; i++ {
go func(id int) {
for {
select {
case x, ok := <-ch:
if !ok {
return
}
fmt.Printf("consumer %d got %d\n", id, x)
case <-done:
return
}
}
}(i)
}关闭 channel 的时机和常见 panic 场景
最常踩的坑是：在还有生产者往 channel 写数据时就 close(ch)，导致 panic: “send on closed channel”。关闭只能由**最后一个生产者**执行，且必须确保所有写操作已完成。
立即学习“go语言免费学习笔记（深入）”；
- 不要在启动生产 goroutine 后立刻
close(ch) - 用
sync.WaitGroup等待所有生产者退出后再关闭 —— 注意WaitGroup.Add()必须在go前调用 - 消费者读到
ok == false表示 channel 已关且无更多数据，此时应退出循环，而不是继续select - 关闭已关闭的 channel 也会 panic，所以只关一次，且只由生产端负责
复杂点在于：当生产者本身依赖外部信号（如 HTTP 请求、文件读取结束）时，done 和 close 的协作顺序极易出错。这时候建议把“是否完成”的状态封装进结构体，而不是靠 channel 关闭来传递语义。
