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