程序常卡死是因为未关闭channel或缺乏退出控制；range会阻塞等待数据，生产者结束后须close(ch)，消费者用range安全遍历，且不可重复close；多消费者读同一channel天然公平，但共享资源需加锁。
用 chan 实现基础生产者消费者时，为什么程序常卡死？
因为没关 channel 或没做退出控制——Go 的 range 会一直阻塞等待新数据，而生产者早结束了却没关闭 chan，消费者就永远等下去。
正确做法是：生产者完成任务后调用 close(ch)；消费者用 range ch 安全遍历（它自动感知关闭）。
- 别在多个 goroutine 中重复
close(ch)，会 panic：panic: close of closed channel - 如果消费者要提前退出（比如超时），不能只依赖
range，得配合select+donechannel - 无缓冲 channel 容易造成生产者和消费者互相等待，上线前务必确认是否需要缓冲：
ch := make(chan int, 100)
如何让多个消费者公平消费同一 channel？
直接起多个 goroutine 读同一个 chan 就行，Go 运行时天然保证：发到 channel 的每个值，只会被一个 goroutine 接收到。
但要注意竞争场景：比如多个消费者都去写同一份日志文件或更新同一数据库行，这时需额外加锁或改用唯一分发逻辑。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 消费者数量不建议远超 CPU 核心数，尤其当处理逻辑含 I/O 或阻塞操作时
- 若需“按 key 路由到固定消费者”，就得自己做分发层，不能依赖 channel 默认行为
- 用
sync.WaitGroup等待所有消费者退出，别只等生产者结束
select 配合 default 在消费者里有什么风险？
加 default 会让 consumer 变成忙轮询，CPU 占用飙升——它不再阻塞，而是反复进入 select，空转检查 channel 是否有数据。
这适合极低延迟要求且能接受资源换响应的场景，但绝大多数服务里是反模式。
- 想非阻塞尝试读一次，用
select+default没问题；想持续消费，就别加default - 真要防止单个 consumer 卡住，应该用
context.WithTimeout包裹处理逻辑，而不是靠default逃逸 - 如果 channel 长期空闲，
select无default会挂起 goroutine，这是预期行为，不是 bug
高并发下 channel 缓冲区设多大才合适？
没有通用值。设太小，生产者频繁阻塞；设太大，内存占用不可控，还可能掩盖下游处理瓶颈。
推荐从实际吞吐倒推：比如每秒最多产生 500 条消息，消费者平均处理耗时 20ms，那理论积压上限是 500 * 0.02 = 10 条，缓冲区设 16 或 32 更稳妥。
- 线上建议用可配置参数（如 flag 或 config），别硬编码
make(chan T, 1024) - 监控
len(ch)和cap(ch)，当len(ch) == cap(ch)频繁出现，说明缓冲区已成瓶颈 - 如果生产速率波动极大（如突发流量），考虑用带限流的中间层，而非一味扩大 buffer
channel 不是万能队列，它不支持重试、持久化、广播或多播。一旦业务需要这些，就得切到 Redis、RabbitMQ 或专用消息队列——别硬扛。
