kafka、rabbitmq、nsq 的选型取决于业务场景：高吞吐+日志留存优先kafka，需注意sarama配置与消费者组参数；灵活路由/ack选rabbitmq，须规避连接非线程安全及ack遗漏；轻量实时通知可选nsq，但受限于消息大小、无原生消费者组及lookupd单点。
Kafka、RabbitMQ、NSQ 三者在 Go 生产环境中不是“哪个更好”，而是“哪个更匹配当前场景”——选错不光是性能差，还会让 consumer 反复重试、offset 同步失败、或根本无法保障消息时序。
吞吐量高且需长期留存日志？优先看 Kafka
Kafka 的分区 + 副本机制天然适合高吞吐+持久化场景，但它的“高”是有前提的：必须批量发送、压缩启用、acks=all 配置得当。Go 客户端用 sarama 时容易踩两个坑：
-
sarama.AsyncProducer默认不保证发送成功，错误被静默丢弃；必须监听Errors()和Successes()channel 才能感知失败 - 消费者组（
ConsumerGroup）中，若session.timeout.ms设太短（如 10s），而业务处理耗时波动大，会频繁触发REBALANCE，导致重复消费 - 日志类场景若只要“最终一致性”，可关掉
enable.idempotence省开销；但订单类场景必须打开，否则网络抖动可能造成消息重复写入
需要灵活路由和复杂 ACK 逻辑？RabbitMQ 更可控
RabbitMQ 的 exchange + binding key + dead-letter 模式，在 Go 中用 streadway/amqp 实现很直观，但它对 Go 开发者最不友好的地方是连接生命周期管理：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
amqp.Connection不是线程安全的，不能在多个 goroutine 里共用；常见错误是全局单例一个conn，然后并发调Channel()，结果 panic 报"invalid memory address" - 手动 ACK 场景下，若业务 panic 未显式调
channel.Ack()或channel.Nack()，消息会卡在 unacked 状态，堆积后阻塞整个 queue - 若要用延迟队列，得依赖插件
rabbitmq-delayed-message-exchange，且 Go 客户端发消息时必须设headers["x-delay"]，不是直接传 delay 参数
轻量实时通知、服务规模小？NSQ 基本零配置就能跑
NSQ 的设计哲学就是“够用即止”，Go 原生支持好，nsqio/go-nsq 库几乎没有学习成本。但它不适合以下情况：
- 消息体超过 1MB 会直接被
nsqd拒收（默认限制），改配置要重启节点，线上不敢轻易动 - 没有原生消费者组概念，靠客户端自己实现 lookupd 发现和 topic 分片，扩容时若新实例上线慢，旧实例可能过载
-
nsqlookupd是无状态的，但它是服务发现的单点；如果它挂了，新 producer/consumer 就无法自动发现 topic，得靠 client 本地缓存 fallback
Go 项目启动前必须确认的三件事
别等压测完才发现选型错了：
- 你的消息是否允许重复？Kafka 在
acks=1下可能丢数据，RabbitMQ 的镜像队列能保不丢但吞吐降 30%+ - 下游消费者是否能接受秒级延迟？NSQ 默认 60s 超时才进
dead_topic，而 RabbitMQ 可配x-message-ttl到毫秒级 - 运维团队是否熟悉该中间件？Kafka 运维成本远高于 NSQ；若团队只有 1 名运维，硬上 Kafka 很可能变成“半夜三点调
log.retention.hours”
真正难的从来不是写 producer.Send()，而是搞清业务对“顺序”“重复”“延迟”的容忍边界——这些边界一旦定错，换中间件的成本远高于一开始多花两小时画张对比表。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
