结论：RabbitMQ + Go 削峰填谷成败关键在于四点闭环——生产者不阻塞（需设Qos+Confirm）、消费者可控速（用Worker Pool+合理prefetch）、消息不丢失（三重持久化+手动ACK）、失败可重试（nack+指数退避+死信兜底），缺一不可。
直接说结论：用 RabbitMQ + Go 实现削峰填谷，关键不在“连上 MQ”，而在于生产者不阻塞、消费者能控速、消息不丢、失败可重试——这四点漏掉任何一环，洪峰来了照样雪崩。
Go 生产者发消息时为什么总卡住？
常见现象是 ch.Publish 调用后 goroutine 长时间阻塞，接口超时。根本原因不是网络慢，而是 RabbitMQ 的 channel 未设置 Qos 或 broker 端积压太多未确认消息，触发了 AMQP 的流控机制（即 publisher flow control）。
- 必须在建立 channel 后立即调用
ch.Qos(1, 0, false)：第一个参数是prefetchCount，设为 1 表示“最多只给消费者发 1 条未确认消息”，避免消费者扛不住时 broker 还拼命推； - 生产者端不要依赖
ch.Publish返回值判断成功——它只表示“投递到 broker 缓冲区”，不保证落地；真正要确认可靠性，得开启ch.Confirm模式并监听 ack/nack； - 如果用了
amqp.Publishing{DeliveryMode: amqp.Persistent}，但 queue 没声明为 durable，消息仍会丢失——DeliveryMode和 queue 声明必须匹配。
RabbitMQ 消费者吞吐上不去，CPU 却跑满？
典型症状是 consumer 吞吐远低于预期，top 看 Go 进程 CPU 高，但日志里没多少处理记录。问题往往出在“同步处理 + 无节制并发”上：每条消息启一个 goroutine 处理，数据库连接池打满、GC 频繁、上下文切换开销爆炸。
- 别用
go handle(msg)直接起 goroutine —— 改用固定 size 的 worker pool，比如sem := make(chan struct{}, 10)控制并发数； - 消费逻辑里避免阻塞 IO（如直连 DB 写入），优先走异步写入队列或批量 flush；
- 注意
msg.Ack()的时机：必须在业务逻辑彻底完成（含 DB commit 成功）后再调用，否则 nack 重发会导致重复消费； - 如果消费耗时波动大，把
prefetchCount从 1 改成稍大值（如 5），但需配合更细粒度的 timeout 控制，防止某条慢消息拖垮整组 prefetch。
消息丢了怎么办？三个必须检查的环节
不是加了 durable 就万事大吉。RabbitMQ 消息丢失通常发生在三个断点：生产者到 broker、broker 存储、broker 到消费者。
立即学习“go语言免费学习笔记（深入）”；
- 生产者端：确认开了
channel.Confirm，且收到ack后才认为发送成功；nack必须重试（带指数退避），不能静默丢弃； - broker 端：queue 创建时必须传
amqp.Table{"x-ha-policy": "all"}（集群模式）或至少确保durable: true+delivery_mode: 2； - 消费者端：关闭 auto-ack，手动调用
msg.Ack()；同时确保 consumer 进程退出前调用ch.Cancel并等待所有未 ack 消息被 broker 重入队（否则进程 kill 会丢消息）。
真正的难点不在代码写几行，而在每个环节都得做“负向设计”：假设网络会抖、broker 会重启、consumer 会 panic、DB 会超时——然后倒推每一步该加什么防护。比如一条消息从 App 提交，到最终落库，中间经过 4 个组件（App → API → RabbitMQ → Consumer → DB），只要其中任意一环没做幂等或重试，就可能出数据不一致。这没法靠单点优化解决，得全链路对齐语义。
