必须用 sync.WaitGroup 等待 worker 退出，因 for range 只感知 channel 关闭而不保证 goroutine 执行完毕；缓冲大小需权衡吞吐与内存，生产者单点 close，消费者只读 channel 保障安全。
用带缓冲 chan 做消费者队列最直接，但必须配 sync.WaitGroup 等待退出，否则主程序常提前结束——这是 90% 新手第一次跑不起来的根本原因。
为什么不能只用 for range 就完事？
看似简洁的 for data := range ch 确实能自动感知 close(ch) 并退出循环，但它只管“读完已关闭的 channel”，不管“goroutine 是否真正执行完毕”。一旦主 goroutine 执行完就退出进程，正在 sleep 或处理中的 worker 会被强制终止。
- 现象：
Worker 1 processing task 3: data-3打印一半，程序就静默退出 - 根本原因：没有同步机制告诉主程序“所有 worker 已退出”
- 正确做法：用
sync.WaitGroup显式计数 +defer wg.Done()，不是靠 channel 关闭“猜”结束
缓冲大小设多少才不卡又不爆内存？
make(chan Task, N) 的 N 不是越大越好，它本质是生产者侧的“等待区”，和消费者吞吐能力强相关。
- 设太小（如
1）：生产者频繁阻塞，尤其在突发任务时丢速明显 - 设太大（如
10000）：内存占用陡增，且掩盖消费瓶颈——你以为是队列没满，其实是消费者卡在 DB 写入或 HTTP 调用上 - 经验值：从
100起步；若日志显示len(ch) == cap(ch)频繁出现，说明消费者跟不上，优先优化 worker 内部逻辑，而非盲目扩 buffer
多个消费者共用一个 chan 时，谁来关 channel？
只有一个角色能调用 close(ch)：**生产者**。消费者绝不可 close，否则会 panic（panic: close of closed channel）。
立即学习“go语言免费学习笔记（深入）”；
- 错误模式：某个 worker 发现自己读到零值，就顺手
close(ch)—— 其他 worker 下一秒就崩溃 - 正确流程：生产者发完全部任务后，单点 close；所有消费者统一用
for task := range ch安全退出 - 进阶提醒：如果生产者是长连接（如监听 Kafka），则永不 close；此时需用
context.Context控制 worker 退出，而不是依赖 channel 关闭
package mainimport ( "fmt" "sync" "time" )
type Task struct { ID int Data string }
func worker(id int, tasks <-chan Task, wg sync.WaitGroup) { defer wg.Done() for task := range tasks { fmt.Printf("Worker %d processing task %d: %s\n", id, task.ID, task.Data) time.Sleep(300 time.Millisecond) // 模拟真实处理耗时 } fmt.Printf("Worker %d stopped.\n", id) }
func main() { taskQueue := make(chan Task, 100) var wg sync.WaitGroup
// 启动 3 个消费者 for i := 1; i <= 3; i++ { wg.Add(1) go worker(i, taskQueue, &wg) } // 生产者：发送 10 个任务 for i := 1; i <= 10; i++ { taskQueue <- Task{ID: i, Data: fmt.Sprintf("data-%d", i)} } close(taskQueue) // ✅ 只有这里能 close wg.Wait() // ✅ 必须等所有 worker 真正退出 fmt.Println("All workers done.")}
最易被忽略的点：worker 函数签名里接收的是
（只读 channel），这既是类型安全提示，也防止误写ch 导致编译失败——Go 的 channel 方向性不是装饰，是并发契约的一部分。
