chan实现任务队列更可控，因其天然支持阻塞、超时、关闭通知和goroutine安全，无需额外依赖即可精确控制并发节奏与生命周期；无缓冲chan易致生产者阻塞僵死，正确做法是设合理缓冲容量并配合select防堵死。
为什么用 chan 实现任务队列比用第三方库更可控
因为 Go 的 chan 天然支持阻塞、超时、关闭通知和 goroutine 安全，不用引入额外依赖就能精确控制并发节奏和生命周期。比如你希望「生产者发完就退出，消费者等所有任务处理完再收工」，用 close() + range 就能自然达成；而很多队列库默认带持久化或重试逻辑，反而在内存任务场景里增加心智负担。
常见错误是直接用无缓冲通道做任务队列：一旦消费者卡住，生产者立刻阻塞，整个流程僵死。正确做法是明确缓冲区大小，并配合超时或 select 降级：
-
tasks := make(chan Task, 100)—— 缓冲容量要大于峰值并发写入量，但别设成math.MaxInt，否则内存失控 - 生产者写入前加
select防堵死：select { case tasks <- task: // 成功 default: log.Println("task queue full, dropped") } - 消费者必须用
for task := range tasks，而不是for { ，否则关通道后会 panic
close() 谁来调？生产者还是消费者？
只有生产者能安全调 close()，且必须确保「所有生产 goroutine 都已退出」。如果多个 goroutine 并发生产，要用 sync.WaitGroup 等待全部完成后再 close，否则消费者可能提前收到关闭信号，漏掉最后一批任务。
典型错误写法：go func() { for _, t := range jobs { tasks 后直接 <code>close(tasks) —— 此时生产 goroutine 还没跑完，close 就执行了。
立即学习“go语言免费学习笔记（深入）”；
正确结构：
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for _, t := range batchJobs {
tasks <- t
}
}()
}
go func() {
wg.Wait()
close(tasks) // 所有生产者退出后才 close
}()消费者怎么优雅退出而不丢任务？
消费者不能靠「收到关闭信号就立刻 return」，因为 range 在通道关闭后会自动退出循环，但最后一轮取出的任务可能还没处理完。必须把任务处理逻辑放在 range 循环内，且不加任何提前 return。
容易被忽略的点：
- 处理任务时发生 panic，会导致该消费者 goroutine 消失，后续任务无人接收 —— 必须包
defer/recover - 想限制最大并发消费者数？别用固定数量 goroutine 死等，改用带缓冲的
sem通道控制：sem := make(chan struct{}, 5) // 最多 5 个并发 go func() { for task := range tasks { sem <- struct{}{} // 获取令牌 go func(t Task) { defer func() { <-sem }() // 归还令牌 process(t) }(task) } }() - 如果任务处理本身需要上下文取消（如 HTTP 请求），要把
context.Context带进任务结构体，而不是在消费者外层传一个全局 ctx
性能瓶颈常卡在哪儿？
不是通道本身，而是任务处理逻辑里的锁、数据库连接池耗尽、或日志同步写磁盘。通道只是管道，真正慢的是下游。
验证方式：把 process(task) 替换成 time.Sleep(1 * time.Millisecond)，观察吞吐是否线性增长。如果不是，说明通道未成为瓶颈。
可调优点：
- 缓冲通道大小设为
runtime.NumCPU() * 2是个安全起点，再根据压测调整 - 避免在消费者里做
json.Marshal或正则匹配 —— 这些 CPU 密集操作会让其他消费者饿死，考虑用 worker pool 分离计算型任务 - 如果任务结构体很大（比如含 []byte），传递指针而非值，减少复制开销
最常被跳过的一步：没给消费者加 recover，导致单个 panic 让整条消费链静默中断。上线前务必检查每个 for range 循环体内是否包裹了错误捕获逻辑。
