Go消息队列并发核心是控节奏、防阻塞、保不丢；缓冲区大小依吞吐与延迟而定，Web服务常用256/512，告警系统用8～32；多消费者需channel分发而非共享range，否则消息丢失。
Go 处理消息队列并发，核心不是“开多少 goroutine”，而是控制消费节奏、避免 channel 阻塞、防止消息丢失——这三点没对齐，再多协程也白搭。
channel 缓冲区设多大？别硬背数字，看实际吞吐和延迟
用 make(chan string, N) 模拟队列时，N 不是越大越好。缓冲太小（如 1）会让生产者频繁阻塞；太大（如 10000）则把内存当队列用，一旦消费者卡住，消息全堆在内存里，OOM 风险陡增。
- 典型 Web 服务场景：每秒约 200 条消息 → 缓冲设
256或512足够，留出 1–2 秒积压余量 - 实时告警类系统：要求低延迟 → 缓冲设
8～32，靠快速消费+失败重试兜底 - 注意：
len(ch)返回当前未读消息数，cap(ch)才是缓冲上限，别混淆
多个 consumer 并发读同一个 channel，为什么消息会丢？
这是新手最常踩的坑：直接起多个 goroutine for msg := range ch，看似并行，实则所有
goroutine 共享一个 channel 迭代器，结果只有第一个拿到消息，其余全空转。
正确做法是让 channel 做“分发中枢”，再由 worker 协程各自取任务：
func main() {
ch := make(chan string, 10)
// 启动 3 个 worker，共用一个输入 channel
for i := 0; i < 3; i++ {
go worker(i, ch)
}
// 生产消息
for i := 1; i <= 10; i++ {
ch <- fmt.Sprintf("task-%d", i)
}
close(ch)
time.Sleep(time.Second)}
func worker(id int, ch
关键点：ch 是只读通道（），所有 worker 从同一源头公平竞争，不会漏消息。
用 RabbitMQ/Kafka/RocketMQ 时，goroutine 数怎么配？
外部消息中间件自带连接池与并发模型，Go 客户端一般不建议每个消息启一个 goroutine。真实瓶颈常在 I/O 等待或业务处理，而非调度本身。
- RabbitMQ：
ch.Consume()返回的本身就是 goroutine-safe 的通道，直接range它即可；若需并发处理，用固定数量 worker 从该 channel 取值，比如 4～8 个（参考 CPU 核心数 × 2） - Kafka（Sarama）：启用
config.ChannelBufferSize控制内部 channel 容量，消费逻辑里别用time.Sleep阻塞主循环，改用context.WithTimeout控制单条处理超时 - RocketMQ：
consumer.Subscribe()内部已做线程池管理，只需确保回调函数内不阻塞、不 panic，否则整条消费线程可能挂死
消息处理失败后怎么重试？别手动 sleep + retry
手动 time.Sleep 重试会卡死整个 goroutine，且无法区分临时失败（网络抖动）和永久失败（数据格式错误）。可靠方案是：失败消息走“死信通道”或带延迟重新入队。
轻量级做法（无中间件时）：
func processWithRetry(msg string, maxRetries int) {
for i := 0; i <= maxRetries; i++ {
if err := doSomething(msg); err == nil {
return // 成功退出
}
if i == maxRetries {
log.Printf("give up on %s after %d retries", msg, maxRetries)
return
}
time.Sleep(time.Second * time.Duration(1<生产环境强烈建议交由中间件处理：RabbitMQ 开启 x-dead-letter-exchange，Kafka 用重试主题 + compact 策略，RocketMQ 支持 DelayLevel 设置延迟重投。
真正难的不是并发数量，而是当消费者崩溃、网络中断、序列化失败时，消息是否还在、能否被重新捕获——这些边界条件，比写 10 个 goroutine 更值得花时间验证。
