不能直接用nats.connect()初始化集群连接，因为其默认建立单点连接，不支持自动故障转移；必须显式传入多个逗号分隔的server url、启用无限重连（nats.maxreconnects(-1)）和设置重连等待时间（nats.reconnectwait），否则节点宕机或网络抖动将导致连接中断且无法切换。
为什么不能直接用 nats.Connect() 初始化集群连接
直接调用 nats.Connect() 会建立单点连接，一旦该 NATS Server 实例宕机或网络抖动，Conn 立即断开且不会自动切换到其他节点——这在秒级高并发场景下等于通知中断。Golang 客户端本身不内置集群发现逻辑，必须显式提供多个 URL 并启用重连机制。
- 必须传入至少两个
server-url（如"nats://10.0.1.10:4222,nats://10.0.1.11:4222"），用逗号分隔 - 务必设置
nats.ReconnectWait(500 * time.Millisecond)和nats.MaxReconnects(-1)，否则默认只重试 10 次就放弃 - 避免使用
nats.NoReconnect()或漏设nats.DisconnectErrHandler，否则连接丢失时无日志、无回调、无感知
如何确保发布（publish）不阻塞主线程且不丢消息
在每秒数千次通知的场景下，同步 Conn.Publish() 可能因 TCP 缓冲区满或网络延迟而卡住 goroutine；而异步 Conn.PublishAsync() 若未监听 Conn.NatsErrorChan()，失败将静默丢失。
- 优先用
Conn.PublishAsync()+Conn.FlushTimeout(250 * time.Millisecond)控制最大等待时间 - 必须启动独立 goroutine 监听
Conn.NatsErrorChan()，捕获如"nats: timeout flushing publish buffer"或"nats: connection closed" - 对关键业务通知（如订单状态变更），建议封装带重试的发布函数：失败时写入本地 WAL 日志，由后台协程择机重发
订阅端如何避免消息堆积和 goroutine 泄漏
用 Conn.Subscribe() 默认创建的 handler 是同步执行的，若处理耗时超过心跳间隔（默认 2 分钟），NATS Server 会认为客户端“卡死”而踢出连接；而 Conn.QueueSubscribe() 若未限制 worker 数量，可能因并发过高拖垮服务。
- 一律使用
Conn.QueueSubscribe(subject, queue, handler)，并配合nats.DeliveryPolicy(nats.AckExplicit)和nats.MaxDeliver(3)防止无限重投 - handler 内部必须调用
msg.Ack()或msg.NakWithDelay()，否则消息永不确认，堆积在 server 内存中 - 用
nats.SetConsumerPendingLimits(1000, 10*1024*1024)限制单个 subscription 的 pending 消息数和字节数，超限时触发Conn.ErrorHandler
集群配置里最容易被忽略的三个硬性约束
NATS 集群不是“加机器就能扩”，Golang 客户端行为高度依赖服务端拓扑与配置，以下三点不满足会导致连接反复失败或消息乱序：
- 所有 NATS Server 必须开启
cluster { port: 6222; }且互相routes连通，仅靠客户端传多个 URL 不等于集群可用 - Golang 客户端必须禁用
nats.UseOldRequestStyle()（已废弃），否则在 2.10+ 版本 NATS Server 上无法正确处理 request/reply - 若使用 TLS，证书 CN/SAN 必须覆盖全部 server 域名/IP，且客户端需设
nats.Secure(&tls.Config{...})，漏掉任一环节都会在重连时静默失败
真正麻烦的不是连不上，而是连上了但部分节点收不到消息——这种问题往往要查 server 日志里的 [INF] Cluster connection created 和 [WRN] No route to destination 才能定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
