NATS 可靠性依赖 JetStream 与客户端行为的精确配对：连接需超时重试、发布须同步校验错误、消费须手动 Ack 与幂等、主题与事件结构须契约化，JetStream 需显式初始化与配置。
连不上、发不出、收不到、重复处理——不是 NATS 有问题，而是没配对 JetStream 和客户端行为。
连接必须带超时、重试和健康检查，否则服务启动就卡死
NATS 默认连接不设超时，DNS 慢、防火墙拦截、服务未就绪都会让 nats.Connect() 无限 hang 住，导致整个服务起不来。
- 必须显式传入
nats.Timeout(5 * time.Second)，单次连接最多等 5 秒 - 用
nats.MaxReconnects(-1)（不是 0 或正数），表示永久重试；配合nats.ReconnectWait(2 * time.Second)避免高频冲击 - 集群部署时 URL 写成逗号分隔：
"nats://n1:4222,nats://n2:4222"，客户端自动轮询并剔除不可用节点 - 连接后立刻检查状态：
if nc.Status() != nats.CONNECTED，失败则记录错误并退出，不带病运行
发布关键消息必须用 Publish() 并检查 error，别信 PublishAsync()
PublishAsync() 发完就走，NATS 不可达或网络抖动时消息静默丢失，且不报错——这在支付、订单等关键路径上等于直接丢业务。
- 订单创建、支付回调等强一致性场景，必须用
js.Publish()（JetStream 模式）并判断err != nil - 失败时写入本地
pending_events表（带唯一索引），由后台 goroutine 定期扫描重发 - HTTP handler 中禁止同步等待 publish 结果；应启动独立 goroutine 发送，并用
recover()捕获 panic - 若真要用异步，必须配
nc.FlushTimeout(5 * time.Second)，否则缓冲区满后新消息直接被丢
消费端必须用 PullSubscribe() + 手动 Ack() + 幂等校验
用 Subscribe() 或 QueueSubscribe() 而不启用 JetStream，消费者掉线期间消息就蒸发；开了 JetStream 却漏掉 nats.ManualAck()，等于白开——消息投递后立即被标记为已处理，重启照样收不到。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
js.PullSubscribe()，手动控制拉取批次和确认时机，避免堆积或丢失 - 订阅时显式指定策略：
nats.DeliverPolicy(nats.DeliverAll)+nats.AckWait(30 * time.Second)+nats.ManualAck() - 处理前查
msg.Header.Get("Nats-Msg-Id")或业务 ID（如order_id），结合数据库唯一索引做幂等 - 所有 DB/HTTP 调用加
context.WithTimeout(ctx, 5*time.Second)，超时直接msg.Nak()重试，不阻塞后续消息
主题名、事件结构、流配置三者必须契约化，否则发布和订阅根本对不上
"order.created" 和 "order.created.v1" 是两个完全无关的主题；用 map[string]interface{} 解包事件，很快会 panic 或静默丢字段；JetStream 流没配 RetentionPolicy，消息存不住。
- 主题名严格字符串匹配，版本升级需显式变更 subject，不能靠通配符糊弄
- 事件结构体必须含
Type和Version字段，例如type OrderCreatedEvent struct { Type string `json:"type"` Version string `json:"version"` } - JetStream 创建 Stream 时必须指定保留策略：
jetstream.InterestPolicy（按订阅者兴趣）或jetstream.WorkQueuePolicy（工作队列语义） - 去重需同时满足：发布时带
nats.MsgId("order-123")，流配置Duplicates: 2*time.Minute，且业务处理耗时不能超过该窗口
最容易被忽略的是：JetStream 不是“连上就自动生效”，它需要显式初始化、显式创建流、显式配置消费者策略——少一步，消息就不持久、不重试、不幂等。别把 NATS 当成 Kafka 的轻量替代，它的可靠性是拼出来的，不是开箱即来的。
