选 RabbitMQ 还是 NATS JetStream，关键看三点：是否需死信队列、下游是否跨语言、事件频率是否超每秒几百条；RabbitMQ 适合强一致性多系统通知，NATS JetStream 适合中高频内部事件。
用 RabbitMQ 还是 NATS JetStream？看这三点就别纠结
别一上来就比吞吐、延迟或社区热度——选错中间件，后期改起来比重写还疼。关键看三件事：你是否需要死信队列处理失败逻辑、下游服务是否跨语言（比如未来要加 Python 风控模块）、事件频率是不是每秒几百条以上。
- RabbitMQ：适合订单创建后必须通知库存、风控、积分三个系统，且任一失败都不能丢消息的场景；
streadway/amqp客户端成熟，但Connection和Channel必须复用，别在handler里每次新建 - NATS JetStream：Go 生态最顺手，
nats-io/nats.go一行连 JetStream，PullSubscribe自带重试与确认语义；适合用户登录广播、配置变更通知这类中高频内部事件 - Kafka：单条消息延迟偏高，小服务用它容易“杀鸡用牛刀”；
segmentio/kafka-go是当前最稳客户端，但WriteTimeout和ReadTimeout必须显式设，否则网络抖动时生产者会卡死
消息体不能传 map[string]interface{}，这是线上事故高发区
传裸字符串或 map[string]interface{} 看似省事，实则埋雷：消费者升级字段时解析直接 panic，跨语言新增 Node.js 消费者时 JSON 反序列化失败，日志里全是 json: cannot unmarshal string into Go struct。
- 所有事件必须用
struct显式定义，带json:标签和注释，例如：type OrderCreatedEvent struct { OrderID string `json:"order_id"` UserID string `json:"user_id"` Total float64 `json:"total"` Timestamp int64 `json:"timestamp"` Version string `json:"version"` // 必加，如 "v1" } - 主题命名带领域和版本：
events.order.created.v1，避免消费者升级时解析失败 - 序列化只用
json.Marshal，禁用gob——它不跨语言，也不兼容未来任何非 Go 服务
消费者不写幂等逻辑，等于没接消息队列
消息重复不是异常，是常态。RabbitMQ 的 basic.nack、NATS JetStream 的重试机制、Kafka 的 rebalance，都会导致同一条消息被多次投递。指望“队列不重发”，等于指望网络永不丢包。
- 幂等是底线：用唯一业务 ID（如
order_id）查库判断是否已处理；或用 RedisSETNX processed:order_12345 true EX 3600记录痕迹 - ACK 必须后置：处理完成后再调
delivery.Ack(false)；若 panic 或 error，调delivery.Nack(true, true)重回队列头部（注意避免无限循环） - 每个消费 goroutine 必须带
context.WithTimeout，超时自动退出，防止某条消息卡死整个 worker
生产端别在 HTTP handler 里同步等消息发成功
用户下单接口响应时间不能被消息发送拖慢。网络抖动、RabbitMQ 重启、JetStream 节点临时不可用——这些都该被隔离，而不是让主流程阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 用
go publisher.Publish(ctx, msg)异步发送，但要注意ctx生命周期，别传入已 cancel 的上下文 - 本地失败（如连接 refused）必须兜底：写入本地
reliable_outbox表（含payload、topic、next_retry_at），由后台定时任务扫描重发 - 不要在 handler 里捕获 panic 后静默吞掉——至少记录
log.Error("failed to publish event", "err", err, "event", msg)，否则问题永远发现不了
最常被忽略的其实是消息生命周期的可观测性：每条消息该带 trace_id，每个消费动作该上报 event_processed_total{type="order_paid",status="failed"} 到 Prometheus。没有追踪和指标，异步链路就是黑盒——出问题时，你连是从哪条消息开始积压的都找不到。
