不能让生产者自己 close(ch)，因为多生产者并发时提前关闭会导致 panic 或数据丢失；应使用 sync.waitgroup 等待全部完成后再由单独 goroutine 统一关闭。
为什么不能让生产者自己 close(ch)？
因为多个生产者 goroutine 同时运行时，谁先 close 就决定了 channel 的生死——close 只能调一次，第二次就会 panic：panic: close of closed channel；更糟的是，如果某个生产者提前 close，其他还在发数据的生产者会立刻触发 panic: send on closed channel。
- 正确做法是：用
sync.WaitGroup跟踪所有生产者完成状态，再由一个独立 goroutine 在wg.Wait()后统一close(ch) - 别在生产者函数末尾写
defer close(ch)——万一它 panic 了，defer不执行，channel 永远不关；或者它没 panic 但还有别的生产者在跑，就又回到“提前关闭”问题 - 消费者完全不用管谁关的 channel，只要用
for data := range ch就行，Go 自动处理关闭信号
带缓冲 channel 的大小怎么定？不是越大越好
设成 make(chan int, 1024) 看起来很“保险”，但实际容易掩盖下游瓶颈、拖慢故障发现、甚至吃光内存。缓冲区本质是背压缓冲器，不是数据暂存盘。
- 估算公式参考：预期峰值 QPS × 平均处理延迟（秒）。比如每秒最多 300 条任务，平均处理耗时 50ms，理论积压上限是
300 × 0.05 = 15，缓冲设32更合理 -
len(ch)是当前队列长度快照，可用来监控积压（如告警len(ch) == cap(ch)频繁出现），但不能用于调度决策——它不保证实时性 - 若想丢弃旧任务防积压，得用
select+default非阻塞发送，而不是靠扩大缓冲
多个消费者怎么确保不漏不重、公平分发？
直接把同一个 ch 传给多个消费者 goroutine，Go 运行时天然保证每个值只被一个消费者收到——这不是轮询，也不是哈希分发，而是随机公平调度，足够绝大多数场景使用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不需要加锁、不需要自己维护队列，
for data := range ch就是标准写法 - 真正要防的是“竞争写”：比如多个消费者都往同一张数据库表插入记录、或写同一个日志文件，这时才需要额外同步（如
sync.Mutex或按 key 分片） - 别为了“绝对均衡”强行加负载均衡逻辑——它会引入锁开销、降低吞吐，还可能让代码更难测
消费者卡住怎么办？超时和取消不能只靠 time.Sleep
time.Sleep 只是模拟耗时，真实场景中单个任务可能因网络、DB 查询、第三方调用而卡死。必须对每个消费动作加超时，否则一个 goroutine 卡住，整个 worker 就废了。
- 推荐用
context.WithTimeout包裹处理逻辑，而不是在循环外套一个time.After——前者控制单任务，后者控制整个消费者生命周期 - 避免在
select循环里反复创建time.After，应提前定义timeout := time.After(5 * time.Second)，否则 timer 泄漏 - 别滥用
select+default做“非阻塞读”来防卡——它会让 goroutine 忙轮询，CPU 拉满；真要试探性读一次，可以，但持续消费必须阻塞等待
最常被忽略的其实是关闭时机和缓冲区语义：关早了丢数据，关晚了 goroutine 泄漏；缓冲设大了像没背压，设小了又频繁阻塞。这些细节不报错，但上线后就是隐性雪崩点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
