必须用 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 main
<p>import (
"fmt"
"sync"
"time"
)</p><p>type Task struct {
ID int
Data string
}</p><p>func worker(id int, tasks <-chan Task, wg <em>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 </em> time.Millisecond) // 模拟真实处理耗时
}
fmt.Printf("Worker %d stopped.\n", id)
}</p><p>func main() {
taskQueue := make(chan Task, 100)
var wg sync.WaitGroup</p><pre class='brush:php;toolbar:false;'>// 启动 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 函数签名里接收的是 <-chan Task（只读 channel），这既是类型安全提示，也防止误写 ch <- task 导致编译失败——Go 的 channel 方向性不是装饰，是并发契约的一部分。
