必须先创建Stream，否则Publish会panic；JetStream需显式初始化并配置存储策略，连接后须调用jetstream.New(nc)或nc.JetStream()检查错误，且服务端必须启用-js参数，客户端需显式设置StorageType、DeliverPolicy、MsgID与Duplicates等关键参数。
必须先建 Stream，否则 Publish 就 panic；JetStream 不是连接后自动可用的“开关”，而是要显式初始化、显式配置存储策略的独立层。
JetStream 连接必须在 nats.Connect() 后立刻初始化
很多人写完 nats.Connect() 就直接调 js.Publish()，结果 runtime panic 报 "JetStream not enabled on server" 或 "nil pointer dereference"。这不是代码写错了，是漏掉了关键一步：JetStream 客户端对象必须主动创建并检查错误。
- 正确顺序是：
nats.Connect()→jetstream.New(nc)（或nc.JetStream()）→ 检查返回的err - 不能把初始化延迟到第一次 publish 时——那时错误堆栈已深，难定位
- 生产环境建议加凭证和重连控制：
nats.UserCredentials("user.creds")、nats.MaxReconnects(60)、nats.ReconnectJitter(100*time.Millisecond, time.Second)
Stream 必须显式创建，且 StorageType 决定是否真持久化
裸连 NATS 发消息，消费者掉线 5 秒再上线，之前的消息就彻底丢了。这不是 bug，是设计如此——原生 NATS 是无状态 Pub/Sub。要持久化，必须调 js.CreateStream()，且重点看 Storage 字段：
-
Storage: jetstream.FileStorage→ 消息落盘，断电/重启不丢（默认值，但显式写出更安全） -
Storage: jetstream.MemoryStorage→ 仅存内存，服务重启即清空，仅适合开发验证或临时指标 - 别只配
Subjects和Name，至少补上RetentionPolicy和Duplicates，否则默认策略可能不符合业务预期
消费者收不到旧消息？大概率是 DeliverPolicy 设错了
流里明明有几百条历史消息，新起的消费者却只收到新发布的那几条——八成是没设 DeliverPolicy，或设成了 DeliverLastPolicy。
-
DeliverAllPolicy：从流开头拉取，适合首次同步或补数据 -
DeliverNewPolicy：只收后续新消息（默认行为），适合实时告警类场景 -
DeliverByStartSequencePolicy或DeliverByStartTimePolicy：精准控制回溯点，调试和故障恢复必备 - 注意：
Durable名字必须一致，否则每次都是新消费者，无法延续上次 offset
消息去重靠 MsgID + Duplicates 窗口，不是开箱即用
金融、订单类业务要求幂等，但 JetStream 不会自动给每条消息算 ID。你得自己传 jetstream.WithMsgID("order-123-001")，且流配置里必须设 Duplicates: 2 * time.Minute，否则去重逻辑不生效。
- 重复窗口单位是秒级，太短容易漏判，太长占更多元数据空间
-
MsgID必须全局唯一且稳定（比如用业务单号+时间戳哈希），不能用随机 UUID - 去重只发生在同一 Stream 内，跨 Stream 不共享重复记录
最易被忽略的一点：JetStream 的持久化能力完全依赖服务端配置。哪怕客户端全写对了，如果启动 nats-server 时没加 -js 参数，或者配置文件里 jetstream.enabled = false，那所有流操作都会静默失败或报错模糊——务必先确认服务端已启用 JetStream。
