Go项目消息队列选型关键在匹配业务真实压力点：Kafka需严控sarama.AsyncProducer错误处理与消费者组超时配置；RabbitMQ须规避连接非线程安全及ACK遗漏；NSQ受限于消息大小、无原生消费者组及nsqlookupd单点风险。
Go 项目里选消息队列，不是比“谁更快”，而是看「你能不能扛住业务的真实压力点」——Kafka 容易因 sarama.AsyncProducer 静默丢错导致消息失踪；RabbitMQ 的 amqp.Connection 被多 goroutine 共用会直接 panic；NSQ 的 nsqlookupd 一挂，新 consumer 就连不上 topic。三个都可能在线上出事，区别只在于出在哪、怎么救。
高吞吐+日志留存必须用 Kafka？先确认这三件事
Kafka 确实吞吐高，但它的性能前提是批量、压缩、强一致配置到位。Go 里用 sarama 时，AsyncProducer 默认不报错，失败消息进黑洞是常态。
-
sarama.Config.Producer.Return.Successes和.Return.Errors必须设为true，否则无法从Successes()/Errors()channel 拿到结果 - 消费者组（
ConsumerGroup）的session.timeout.ms别设太短；业务处理若常超 10s，建议调到 45s 以上，否则频繁 rebalance 导致重复消费 - 订单类场景必须开
enable.idempotence=true；日志类可关，省掉幂等性开销，但得接受小概率重复写入
RabbitMQ 的 ACK 和连接管理最容易翻车
streadway/amqp 库写起来顺，但 runtime 错误往往在上线后才暴露：连接非线程安全、ACK 漏发、延迟消息依赖插件。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
amqp.Connection是单例但非并发安全，不能全局存一个然后多个 goroutine 同时调Channel()；正确做法是每个 worker 自己Dial或用连接池封装 - 手动 ACK 场景下，只要 consumer goroutine panic 或提前 return，没调
msg.Ack()或msg.Nack()，消息就卡在 unacked 状态，queue 积压后整个 channel 会被 broker block - 要用延迟消息，得装
rabbitmq-delayed-message-exchange插件，且发消息时必须往headers里塞"x-delay"，不是传 delay 参数——客户端库不帮你转
NSQ 看似简单，但扩容和单点问题藏得深
nsqio/go-nsq 上手快，但它的“轻量”是牺牲了部分运维弹性换来的。适合小团队快速上线，不适合对 SLA 有硬性要求的系统。
立即学习“go语言免费学习笔记（深入）”；
- 默认消息体上限 1MB，超限直接被
nsqd拒收；改max-msg-size要重启节点，线上不敢动 - 没有原生消费者组，靠 client 主动向
nsqlookupd发现 topic 和查找 producer；新实例上线慢，旧 consumer 可能瞬间过载 -
nsqlookupd是无状态的，但它是服务发现单点；它挂了，新启动的 producer/consumer 无法自动发现 topic，只能靠 client 本地缓存 fallback，缓存过期就断连
真正难的不是选哪个，而是搞清你的“不可退让项”：要不要消息顺序？能否容忍分钟级不可用？有没有人力盯 nsqlookupd？这些细节一旦模糊，再标准的选型文档也救不了上线后的反复 rollback。
