Go语言NATS消息系统入门教程

本文深入剖析了Go语言中使用NATS消息系统（尤其是JetStream持久化层）的五大关键陷阱：从生产环境必配的重连策略、安全凭证与TLS配置，到JetStream流初始化缺失导致的panic；从RetentionPolicy选型错误引发的消息丢失，到MsgID缺失和并发发布引发的重复与乱序；再到订阅策略不匹配造成的消费断层——所有看似神秘的“消息丢了”“重复了”“顺序乱了”，实则都源于客户端配置与行为未与JetStream语义对齐，而绝非服务端缺陷。掌握这些隐性约定，才能让NATS在高可用场景下真正可靠运转。

怎么连上NATS服务器，又不被网络抖动搞崩

裸调用 nats.Connect(nats.DefaultURL) 在开发时能跑通，但一上生产就掉线不重连——这不是你的代码问题，是默认配置根本没开重试。

• 必须显式加重连策略：nats.MaxReconnects(60)、nats.ReconnectWait(2*time.Second)、nats.ReconnectJitter(100*time.Millisecond, time.Second)
• 别把密码写死在 URL 里，比如 "nats://user:pass@host:4222"；改用 nats.UserCredentials("user.creds") 加载凭证文件
• 如果启用了 TLS，记得用 "tls://..." 协议前缀，且服务端证书要可信，否则 Connect 会静默失败（不是报错，是卡住）

发出去的消息，为什么消费者收不到

默认 NATS 是纯内存转发，订阅者离线期间发布的消息直接丢弃——这设计没错，但很多人误以为“发了=收到了”。

• 想“不丢”，必须启用 JetStream 并创建流（Stream），光连上 JetStream 不够，得调 js.AddStream() 显式声明
• 创建流时，RetentionPolicy 必须设对：jetstream.InterestPolicy（只存活跃订阅者需要的）或 jetstream.WorkQueuePolicy（每条只投一次）
• 订阅时要用 nats.DeliverPolicy(nats.DeliverAll) 才能从头消费；若用 DeliverLastPerSubject，重启后可能跳过中间事件

JetStream 发消息重复/乱序，是不是服务端 bug

不是。重复和乱序都源于客户端用法不对，NATS 本身不保证顺序，也不自动去重。

• 去重要生效，发布时必须带 ID：js.Publish("orders.created", data, nats.WithMsgID("order-123"))，ID 得业务唯一（不能是 uuid.New()）
• 流配置里的 Duplicates: 2*time.Minute 是去重窗口，不是保留时间；如果处理耗时超 2 分钟，重复仍会发生
• 多 goroutine 并发调 js.Publish() 同一 subject，消息大概率乱序；关键顺序场景，得用单 goroutine + channel 缓冲，或加业务层序列号校验

为什么第一次 js.Publish() panic

因为 JetStream 上下文没提前初始化。NATS 客户端连接后不会自动准备 JetStream 能力，得手动获取 jetstream.Context。

• 连接后立刻执行：js, err := jetstream.New(nc)，别等到 publish 前才调
• 如果忘了这步，第一次 js.Publish() 会 panic：“context not ready”，错误信息里没有明确提示，容易卡在调试里绕半天
• 建议在服务启动阶段统一做健康检查：连上 NATS → 初始化 jetstream.Context → 尝试 js.AccountInfo() 确认可用

JetStream 的配置项和客户端行为耦合极深，很多问题表面是“消息丢了”或“重复了”，根子都在流定义、发布方式、订阅策略三者没对齐。最容易被忽略的是：流创建是一次性动作，改配置得删了重建，不是热更新。

到这里，我们也就讲完了《Go语言NATS消息系统入门教程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！