必须严格控制 channel 生命周期、缓冲策略和 worker 退出逻辑，否则将导致 CPU 狂飙、消息丢失、goroutine 泄漏；关闭 channel 须由唯一生产方在全部任务完成后执行，多生产者需用 sync.WaitGroup 同步；缓冲区大小应基于峰值并发量设定而非 worker 数量；worker 需通过显式 done 信号实现优雅停机。
Go 微服务里用 channel 做任务分流，不是“能用就行”，而是必须控制好生命周期、缓冲策略和 worker 退出逻辑，否则上线后 CPU 狂飙、消息丢失、goroutine 泄漏全是常态。
channel 关闭时机不对直接导致死锁或 panic
常见错误是生产者 goroutine 自行退出却不 close(tasks)，或者多个生产者没用 sync.WaitGroup 同步就调用 close。结果就是：for task := range tasks 永远卡住，worker 不退出；或者 close 被重复调用，panic: “close of closed channel”。
- 只允许任务生产方（且仅一方）调用
close(tasks)，通常放在生产逻辑末尾的defer close(tasks)最稳妥 - 多个生产者时，必须用
sync.WaitGroup计数，全部完成后再 close —— 不是“谁先做完谁关”，而是“全部做完才关” - worker 不能假设
tasks一定会被关闭；在关键路径上加超时或用select+default防止无限阻塞
缓冲区大小和 worker 数量不是线性配比关系
很多人按 “10 个 worker 就配 make(chan Task, 10)”，这是典型误解。buffer 大小影响的是背压传导速度和内存占用，跟并发数没有数学绑定。
- 无缓冲 channel（
make(chan Task)）适合低延迟、强实时场景，但要求 producer 和 consumer 速率高度匹配，否则任一方会阻塞 - 有缓冲 channel（如
make(chan Task, 100)）解耦更彻底，但 buffer 过大会掩盖下游处理瓶颈；建议设为预估峰值并发量的 2–3 倍 - 监控
len(tasks)和cap(tasks)比值，持续 >0.8 就说明消费跟不上，该扩容 worker 或优化单任务耗时
worker 退出信号必须显式传递，不能靠 channel 关闭隐式感知
微服务需要优雅停机：收到 SIGHUP 或 HTTP /shutdown 时，worker 应停止拉取新任务、处理完手头任务再退出。仅靠 close(tasks) 不够——它不区分“任务发完了”和“我要下线了”。
- 加一个单独的
done chan struct{}，所有 worker 的for循环都套在select里：case task := 和 <code>case - 主协程收到停机信号后，先 close(tasks)，再 close(done)，确保 worker 不再读新任务，且能安全退出循环
- 避免在 worker 内部用
time.Sleep等待退出，要用select+default+ 短暂time.Sleep实现非阻塞轮询
大结构体传值拷贝开销远超预期
如果 Task 包含 []byte、map[string]interface{} 或嵌套指针，每次 tasks 都触发一次完整深拷贝，GC 压力陡增，尤其在图文处理类微服务中极易成为瓶颈。
- 小于 64 字节的小结构体（如仅含 2–3 个
int/string）传值更高效，编译器可做逃逸分析优化 - 含二进制数据的任务，改用
*Task传指针，但必须确保Task生命周期覆盖整个处理流程——别在 goroutine 外提前释放内存 - 更彻底的解法：任务 channel 只传 ID 或 URL（如
type Task struct { ID string; FileURL string }），worker 自行下载/加载，避开大对象序列化和拷贝
真正难的从来不是“怎么写通”，而是当 QPS 从 100 涨到 5000、单任务耗时从 200ms 延长到 2s 时，channel 缓冲是否溢出、worker 是否堆积、退出信号是否被丢弃——这些细节藏在日志里、监控里、压测后的 GC trace 里，不在示例代码里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
