Go channel不适合作为消息队列，仅适用于进程内轻量任务队列；需用只写/只读类型声明、结构化任务体、显式关闭与range消费；应限制worker数量并实现背压控制，避免缓冲滥用和goroutine泄漏。
用
做任务队列，别直接当“消息队列”用
Go 的
本身不是消息队列系统，它没有持久化、重试、ACK、消费者组等能力。拿它做“简单任务队列”，只适用于进程内短生命周期、不丢任务可接受、并发量可控的场景（比如批量处理日志、预热缓存、发通知）。一旦需要可靠性或横向扩展，得换
、
或
。
是最简可行结构，但要注意类型和关闭时机
定义任务通道时，推荐用
（只写）和
（只读）明确方向，避免误操作。任务体建议封装成 struct 而非裸 map 或 string，方便加字段（如
、
、
）。
常见错误是生产者提前 close(
)，导致消费者收到零值还继续处理。正确做法是：由生产者发完所有任务后 close，消费者用
自动退出；或者用
显式判断。
别用
全局暴露，易引发类型断言 panic
如果任务有优先级，不要靠多个 channel 拼接——容易阻塞，改用带权重的 select + 辅助 channel
关闭 channel 前确认所有 goroutine 已退出，否则会 panic
worker 启动数量要控制，别无脑
每个任务起一个 goroutine 看似简单，但没限流会迅速耗尽内存或打爆下游服务。应该用固定数量的 worker 从 channel 消费：
立即学习
“
go语言免费学习笔记（深入）
”；
这里
是关键参数：它决定了最大并发数，也隐含了缓冲区压力上限。若任务处理时间波动大，可配合
或
加超时控制。
worker 数量 ≠ CPU 核心数，要按任务 I/O 特性调优（CPU 密集型建议 ≤ GOMAXPROCS，I/O 密集型可适当提高）
别在 worker 里 recover() 捕获 panic 后吞掉错误——至少 log 并计数，否则失败静默
如果任务需返回结果，用另一个
回传，别用共享变量
缓冲 channel 不等于“队列容量”，它只是 goroutine 协作的润滑剂
声明
只表示最多缓存 100 个未消费任务，不是说“队列最大长度为 100”。一旦满载，生产者会阻塞，除非你用
+
做非阻塞发送（此时可能丢任务）。
真正需要“容量限制+拒绝策略”的场景，应该自己包装一层：
这个
分支才是控制背压的关键点，而不是依赖缓冲大小本身。
缓冲大小设为 0（unbuffered）时，生产者和消费者必须同时就绪才能传递，适合强同步场景
缓冲太大（比如 10000）容易掩盖性能问题，让内存占用虚高且延迟不可控
别把 channel 当作通用数据容器反复读写——它设计初衷是 CSP 通信，不是 slice 替代品
实际跑起来最常被忽略的是：没给 worker 加
就 exit 主程序，或者忘了在
里处理 context.Done() 导致无法优雅停止。这些细节比“怎么启动 goroutine”更影响稳定性。
channelchannelRabbitMQNATSRedis Streamschan<- interface{}chan<- interface{}<-chan interface{}IDCreatedAtRetryCountchrange chfor task, ok := <-ch; ok; task, ok = <-chchan interface{}go f(task)for i := 0; i < 3; i++ {
go func() {
for task := range tasks {
process(task)
}
}()
}3time.AfterFunccontext.WithTimeout<-chan Resultmake(chan Task, 100)selectdefaulttype TaskQueue struct {
ch chan Task
limit int
}
func (q *TaskQueue) Push(t Task) error {
select {
case q.ch <- t:
return nil
default:
return errors.New("queue full")
}
}
defaultsync.WaitGroupprocess()