裸调用nats.connect易因网络抖动断连不恢复，需显式配置重连策略（maxreconnects、reconnectwait、reconnectjitter）、tls前缀、凭证分离，并初始化jetstream上下文；消息持久化须服务端启用jetstream、客户端创建流、订阅启用durable与deliverall。
裸调用 nats.Connect 在本地能发第一条消息，但一上生产就断连不恢复、消息“消失”、消费者重启后收不到历史数据——这不是 NATS 有问题，是客户端配置和用法没对齐服务端能力。
怎么连上 NATS 服务器又不被网络抖动搞崩
默认连接不重试、不设超时、不验健康，一次抖动就卡死或静默断开。必须显式加策略：
-
nats.MaxReconnects(60)：别用 -1（无限重连），容易压垮服务端 -
nats.ReconnectWait(2 * time.Second)：固定间隔太生硬，配合 jitter 更稳 -
nats.ReconnectJitter(100*time.Millisecond, time.Second)：避免所有实例同一时刻重连 - 密码别写在 URL 里，比如
"nats://user:pass@host:4222"；改用nats.UserCredentials("user.creds")加载凭证文件 - 启用了 TLS？URL 必须用
tls://前缀，且服务端证书要可信，否则Connect()会卡住不报错
js.Publish 第一次 panic 是为什么
不是代码写错，是 jetstream.Context 根本没初始化。NATS 客户端不会自动准备 JetStream 能力。
- 连接成功后立刻执行：
js, err := nc.JetStream()，并检查err - 建议加健康检查：调
js.AccountInfo()确认上下文可用，失败则提前退出 - 别等到
js.Publish()前才调，否则首次调用 panic 报错是"context not ready"，信息模糊难定位
消息“不丢”需要哪三步才真正生效
纯 NATS 是内存转发，消费者掉线期间的消息直接丢弃——这是设计，不是 bug。想持久化，三件事缺一不可：
- 服务端启用 JetStream：
nats-server -js或配置文件含jetstream: { store_dir: "/data/jetstream" } - 客户端连接后调
js.AddStream(&nats.StreamConfig{Name: "ORDERS", Subjects: []string{"order.*"}})显式创建流 - 订阅时用
nats.DeliverPolicy(nats.DeliverAll)+nats.Durable("processor-name")，否则每次都是全新 offset
去重和顺序控制为什么总失效
JetStream 支持去重和有序，但全靠客户端配合。服务端不会替你生成 ID，也不会帮你串行发布。
- 每条消息必须带业务唯一 ID：
nats.WithMsgID("order-20260526-001")，ID 必须是业务标识（如 order_id），不是uuid.New() - 流配置里的
Duplicates: 2*time.Minute是去重窗口，不是保留时间；若处理耗时超 2 分钟，重复仍会发生 - 多 goroutine 并发
js.Publish()到同一 subject，顺序无法保证；关键顺序场景必须用单 goroutine + channel 缓冲，或按业务逻辑加序列号
最容易被忽略的是：流创建是一次性动作，改配置得删了重建，不是热更新；JetStream 的配置项和客户端行为耦合极深，很多问题表面是“消息丢了”或“重复了”，根子都在流定义、发布方式、订阅策略三者没对齐。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
