根本原因是未妥善处理阻塞、关闭和goroutine生命周期；需用select+default/超时写入、for range配合唯一生产者关闭channel、WaitGroup等待完成，并依QPS与耗时设缓冲容量。
为什么用 channel 做任务队列容易卡死或漏任务
根本原因不是 channel 不行，而是没处理好阻塞、关闭和 goroutine 生命周期。比如向已关闭的 chan int 发送数据会 panic；从空的无缓冲 channel 读取会永久阻塞；goroutine 启动后没等它消费完就退出，任务就丢了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 任务生产者必须用
select+default或带超时的select写入，避免阻塞主线程 - 消费者 goroutine 要用
for range读取，但前提是生产者明确关闭 channel —— 别在还有任务要发时就关 - 关闭 channel 的责任应只由**唯一生产者**承担，多个 goroutine 同时关会 panic
- 如果任务可能失败重试，别把重试逻辑塞进消费者函数里直接递归调用，容易栈溢出；改用重新写回 channel（注意容量和背压）
buffered channel 容量设多少才不拖慢吞吐又不爆内存
没有通用值。设太小（如 make(chan Task, 1)），生产者频繁阻塞，调度延迟高；设太大（如 make(chan Task, 100000)），内存占用不可控，且掩盖了消费者处理慢的问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先按预期峰值 QPS × 平均处理耗时（秒）估算积压量，例如 1000 QPS × 0.2s = 200，初始可设
make(chan Task, 256) - 上线后通过
len(ch)和cap(ch)打点监控积压率，持续 >70% 就要调大或优化消费者性能 - 别用
len(ch) == cap(ch)当作“队列满”的判断依据来限流——这只能反映瞬间快照，竞态下不准；改用带超时的select尝试写入 - 如果任务大小不固定（比如含 []byte），缓冲区实际内存占用远超
cap表面值，需按典型 payload 大小反推
如何安全关闭任务队列并等待所有任务完成
用 close() 只是通知“不再有新任务”，不等于“当前任务已处理完”。常见错误是 close 后直接 return，导致正在运行的 goroutine 被粗暴终止。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.WaitGroup管理活跃消费者：每启动一个消费者 goroutine 就wg.Add(1)，处理完一个任务后wg.Done() - 关闭 channel 前，确保所有生产者已停止发任务（比如用另一个
done chan struct{}控制生产循环） - 关闭 channel 后，调用
wg.Wait()等待所有消费者退出，再做收尾（如关闭结果 channel） - 别在消费者里用
if ok := 单次检测就退出——<code>for range ch才能自然退出，且保证收完所有已入队任务
什么时候不该用 channel 做任务队列
当需要优先级、延时执行、持久化、跨进程/重启恢复，或者任务量极大（百万级/秒）且对延迟敏感时，channel 就不合适了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 要按时间触发（如定时任务），用
time.Timer或第三方库robfig/cron，别往 channel 塞“未来任务”硬等 - 要优先级（如 admin 任务 > user 任务），channel 本身无序，得拆成多个 channel + select 多路复用，维护成本陡增，不如用
container/heap自建优先队列 - 要防止单点故障或支持水平扩展，channel 是纯内存结构，进程挂了全丢，此时该上 Redis List + Lua 或 Kafka
- 调试困难：无法像消息中间件那样查堆积、重放、跳过坏任务——channel 没这些能力，别强行补丁
channel 是 Go 的并发原语，不是万能队列。它适合短生命周期、同进程内、强实时性、低复杂度的任务分发。一旦需求超出这个边界，换方案比硬扛更省力。
