应在配置加载完成后再初始化nats客户端，使用publish()处理关键消息并检查error，用queuesubscribe()实现负载分摊，设置maxinflight防卡死，订阅需在服务启动后建立。
怎么在Golang Web服务里连上NATS，而不是一启动就panic
连不上NATS最常见原因是客户端初始化时机不对或配置没加载成功。Kratos这类框架里，main.go中直接调用 nats.Connect() 但此时配置还没解析完，conf.Nats.URL 可能是空字符串，导致连接地址变成 nats://，报错 nats: no servers specified。
- 必须等
config.ToType(&conf.Nats)执行完再初始化 NATS 客户端 - 连接失败要加重试逻辑，别让整个服务起不来；
nats.Connect("nats://localhost:4222", nats.MaxReconnects(-1), nats.ReconnectWait(2*time.Second)) - 别用
defer nc.Close()在initNATS函数里——那会立刻关掉连接；应该把*nats.Conn存进app的 DI 容器或全局变量，由应用生命周期统一管理
发消息时用 Publish 还是 PublishAsync，选错就丢数据
Publish() 是同步阻塞，等服务器 ACK 才返回；PublishAsync() 是异步非阻塞，发出去就继续执行，但若 NATS 服务不可达或网络抖动，消息可能静默丢失，且不抛错。
- 业务关键消息（如订单创建、支付回调）必须用
Publish()，并检查返回的error - 日志、埋点、通知类弱一致性消息可用
PublishAsync()，但得配nc.FlushTimeout(5*time.Second)防止缓冲区积压 - 别忘了主题（subject）是纯字符串匹配，
"order.created"和"order.created.v1"是两个完全无关的主题，订阅端必须严格一致
消费端用 ChanSubscription 还是 QueueSubscribe，决定并发模型
Web服务里常误用 Subscribe() 处理高吞吐事件，结果所有消息串行进一个 goroutine，CPU 利用率低、延迟飙升。而 QueueSubscribe() 支持多实例负载分摊，才是微服务常态。
-
Subscribe("events.user.login")：所有实例都收全量消息，适合广播类场景（如刷新本地缓存） -
QueueSubscribe("events.user.login", "user-processor-group")：同组内多个消费者自动分摊消息，适合订单处理、积分发放等任务型逻辑 - 用
ChanSubscription时记得开足够多 goroutine 消费 channel，否则 channel 堵塞会导致 NATS 内部缓冲溢出，连接被踢 - 务必设置
MaxInflight(256)，否则默认只允许 64 条未确认消息，高并发下迅速卡死
为什么消息偶尔重复，又或者根本收不到
NATS Core（非 Streaming）本身不保证“恰好一次”，只提供“至少一次”语义。重复是因为客户端超时重发，收不到则常因订阅晚于发布、或连接断开后没重订。
立即学习“go语言免费学习笔记（深入）”；
- 发布前先
nc.Status()确认连接状态，避免往断连连接发消息 - 订阅必须在服务启动完成后再建立，别放在
init()函数里——那时 event loop 还没跑起来 - 用通配符如
"events.>"订阅时，注意>必须在末尾，"events.>.v1"是非法 subject，会静默失败 - 开发环境别依赖 localhost:4222，Docker Compose 启动 NATS 时记得暴露 4222 和 6222（监控端口），否则健康检查和调试全抓瞎
