直接用 channel 做任务队列易出问题：无缓冲导致阻塞和 goroutine 泄漏；缺乏重试、超时、失败隔离，panic 会终止整个消费者；无法动态伸缩 worker 或监控积压；无持久化致进程退出丢任务。
为什么直接用 channel 做任务队列容易出问题
Go 的 channel 天然适合做简单协程通信，但**不能直接当生产-消费型任务队列用**。常见陷阱包括：
— 无缓冲 channel 阻塞发送方，导致任务提交失败或 goroutine 泄漏
— 缺乏重试、超时、失败隔离机制，一个 panic 会 kill 整个消费者
— 无法动态伸缩 worker 数量，也无法监控积压任务数
— 没有持久化，进程退出后任务全丢
用 buffered channel + worker pool 实现轻量调度
适合内存内短生命周期任务（如日志归档、通知推送），核心是控制并发、避免阻塞、兜住 panic：
- 用
make(chan Task, N)创建带缓冲的 channel，N 是最大待处理任务数，防止内存无限增长 - 启动固定数量的 worker goroutine，每个都用
for range消费 channel，内部包recover() - 提交任务时加超时控制，避免调用方被卡死
- 不要在 channel 中传大对象，优先传指针或 ID，减少拷贝
type Task struct {
ID string
Data []byte
Exec func()
}
func NewWorkerPool(queueSize, workerNum int) *WorkerPool {
return &WorkerPool{
tasks: make(chan Task, queueSize),
}
}
func (wp *WorkerPool) Start() {
for i := 0; i < workerNum; i++ {
go func() {
for task := range wp.tasks {
defer func() {
if r := recover(); r != nil {
log.Printf("task %s panicked: %v", task.ID, r)
}
}()
task.Exec()
}
}()
}
}
func (wp *WorkerPool) Submit(task Task) bool {
select {
case wp.tasks <- task:
return true
default:
return false // 队列满，拒绝任务
}
}
channel 关闭后 range 不会自动退出？得手动管理
很多人误以为关闭 channel 后 for range 就立刻结束，其实它只在 channel **变空且关闭**时才退出。如果关闭前还有未读数据，range 会继续读完才停——这对任务队列意味着：你关了 channel，但 worker 还在处理旧任务，此时新增 submit 会 panic。
- 正确做法：用
sync.WaitGroup等待所有 worker 完成，再关闭 channel - 或者改用
for { select { case t := 主动退出 - 别依赖
close(ch)触发 worker 退出，那是反模式
真正要上生产？绕不开 broker 和重试逻辑
只要任务不能丢失、需要跨进程/机器分发、或执行时间超过几秒，就必须引入外部 broker（如 Redis、RabbitMQ、NATS）和序列化协议（如 JSON、Protocol Buffers）。Go 标准库的 channel 本质是内存共享通信，不是消息队列。
立即学习“go语言免费学习笔记（深入）”；
-
github.com/hibiken/asynq（Redis 后端）支持延迟任务、失败重试、Web UI -
github.com/ThreeDotsLabs/watermill适合事件驱动架构，可插拔多种 broker - 自己封装时，务必把「投递成功」和「执行成功」分开：先存 DB/Redis，再发 channel 触发执行，失败时从存储恢复
channel 是调度的“最后一公里”，不是队列本身。漏掉持久化、幂等、可观测性中的任一环，上线后就会在凌晨三点收到告警。
