本地开发用单节点nats-server即可，默认监听0.0.0.0:4222；go客户端需显式配置重连策略，启用jetstream后须立即创建jetstream.context，凭证应通过nats.usercredentials加载文件而非硬编码url。
怎么连上NATS服务器不翻车
本地开发直接用 nats-server 单节点就行，别一上来就搞集群。默认监听 0.0.0.0:4222，Go 客户端用 nats.Connect(nats.DefaultURL) 就能连上——但这是“裸连”，没重试、没超时、没健康检查。
- 生产环境必须显式配置重连策略：
nats.MaxReconnects(60)、nats.ReconnectWait(2*time.Second)、nats.ReconnectJitter(100*time.Millisecond, time.Second)，否则网络抖动时连接断了就卡死 - 如果 NATS 启用了 JetStream，连接后要立刻创建
jetstream.Context，不能等发消息时才初始化，否则第一次js.Publish()可能因上下文未就绪而 panic - 别把
nats://user:pass@host:port这种带密码的 URL 写死在代码里，改用nats.UserCredentials("user.creds")加载凭证文件，避免密钥泄露风险
发布-订阅模式下，消息到底丢不丢
默认 NATS 是纯内存转发，消费者掉线期间发布的消息直接丢弃——这不是 bug，是设计。想“不丢”，必须启用 JetStream 并配置流（Stream）。
- 创建流时必须指定
Subjects和RetentionPolicy，比如RetentionPolicy: jetstream.InterestPolicy或jetstream.WorkQueuePolicy，否则即使开了 JetStream，消息也不会持久化 - 订阅时用
js.Subscribe("orders.created", handler, nats.DeliverPolicy(nats.DeliverAll))才能从头消费；若用DeliverLastPerSubject，重启后可能跳过中间事件 - 别依赖“自动重发”：NATS 不保证 exactly-once，只保证 at-least-once，所以消费者必须自己做幂等，比如用
order_id去重 + 数据库唯一索引拦截
JetStream 发布时怎么避免重复和乱序
JetStream 本身支持去重，但得手动开，而且窗口期得设对。乱序问题则和发布者行为强相关——不是服务端问题，是客户端没按规范用。
- 发消息必须加
nats.WithMsgID("order-123")，否则Duplicates配置无效；ID 要业务唯一，不能用uuid.New()一类无意义随机值 - 流配置里的
Duplicates: 2*time.Minute是去重窗口，不是“保留时间”。如果业务处理耗时超过这个值，重复消息仍可能被接受，得同步调大该值或优化处理逻辑 - 别在循环里并发调用
js.Publish()而不控制顺序：NATS 不保证多 goroutine 发布的时序，同一 subject 下消息可能乱序。需顺序关键场景，应串行发布或用单个 goroutine + channel 缓冲
微服务间事件结构怎么定义才不至于后期崩溃
事件体不是越灵活越好，JSON 里没 type 和 version 字段，等于没契约。下游加个字段、改个语义，上游一发，下游全跪。
立即学习“go语言免费学习笔记（深入）”；
- 每个事件 struct 必须嵌入公共头：
Type string `json:"type"`和Version string `json:"version"`，比如"type": "order.created", "version": "v2" - Payload 别用
map[string]interface{}或json.RawMessage，为每类事件定义具体 struct，反序列化时才能类型安全校验 - 时间字段统一用
time.Time+json:"timestamp,string"标签，避免字符串解析失败或时区错乱；别存 Unix timestamp int64，可读性差且易溢出
JetStream 的流和消费者状态是外部资源，不是代码里声明了就自动存在。上线前漏跑 CreateStream 或 CreateConsumer，服务启动成功但消息进不来——这种问题查日志都难定位，得靠部署流程兜底。
