必须由独立goroutine在wg.Wait()后统一close(ch)，因多生产者自行关闭易致panic、数据丢失或消费者阻塞；单生产者自关看似可行但扩展后风险高。
直接用 chan 做任务队列，90% 的线上事故都出在「关通道时机错」和「多生产者竞争写入」上——不是数据丢就是 panic，根本扛不住真实业务流量。
为什么 close(ch) 不能由任意一个生产者调用
Go 的 channel 关闭是单向、不可逆操作。一旦某个生产者提前 close(ch)，其他还在运行的生产者继续往里发数据，立刻触发 panic: send on closed channel。
常见错误场景：
- 多个
go producer(ch, wg)并发启动，每个都带defer close(ch) - 主 goroutine 在启动完所有生产者后立刻
close(ch)，但此时部分生产者还没执行完 - 消费者还没启动完，通道就被关闭，导致
range ch立即退出，任务漏处理
正确做法只有一条：用独立 goroutine 监听 sync.WaitGroup 完成后再关通道。
立即学习“go语言免费学习笔记（深入）”；
select + default 是防止生产者阻塞的唯一可靠手段
无缓冲通道或满载的缓冲通道会让 ch 永久阻塞，拖垮整个生产逻辑。别指望靠增大缓冲区解决——<code>make(chan Task, 1000) 只是把 OOM 提前了。
必须用非阻塞写入保障生产者不卡死：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
select是唯一能实现“尝试发送、失败就走默认路径”的语法 -
default分支必须存在，否则 select 会一直等待（等同于阻塞） - 失败后的策略要明确：丢弃、重试、降级写本地队列、打告警，不能空跑
示例关键片段：
select {
case tasks <- task:
default:
log.Warn("task dropped: channel full")
// 或：retryQueue.Push(task)
}消费者用 for range ch 就够了，别手动检查 ok
很多人写 for { val, ok := ，纯属多余且危险。只要通道关闭时机正确，<code>range 自动退出是最简洁、最安全的方式。
但前提是：
- 通道只能由「生产者全部完成」后那个专用 goroutine 关闭
- 消费者不能在接收中途自己
close(ch)（语法允许但语义错误） - 不要在消费者里起新 goroutine 再往同一
ch写数据（违反单向原则）
额外提醒：如果消费者需要返回结果，别往原通道塞回值——用单独的 results chan，避免污染任务流。
缓冲区大小不是性能参数，而是背压控制开关
make(chan int, N) 的 N 不代表吞吐量越高越好。它本质是「允许积压多少未消费任务」的硬上限。
-
N = 0（无缓冲）：强制同步，生产者必须等消费者就绪，适合低频强一致性场景 -
N = 10~100：典型任务队列，平衡延迟与内存占用 -
N > 1000：除非你明确知道每条任务只占几字节且内存充足，否则极易因积压引发 GC 压力或 OOM
真正影响吞吐的是消费者并发数和单任务处理耗时，不是缓冲区大小。上线前务必用真实负载压测，而不是凭感觉设个大数字。
最易被忽略的一点：channel 方向声明（chan 和 <code>）不是可选项，是类型安全的底线。函数参数写成 <code>func worker(tasks ，编译器就能拦住你在里面误写 <code>tasks ——这种错误在线上几乎无法排查。
