不要自己封装nsq client，应直接使用官方go-nsq客户端；它已内置连接池、自动重连与消息超时机制，自行封装易导致重试语义丢失、消息丢失或maxinflight误配引发堆积。
NSQ 在 Go 微服务里到底要不要自己封装 client？
不要。直接用官方 nsqgo 客户端（即 github.com/nsqio/go-nsq），它已足够稳定、轻量，且原生支持连接池、自动重连、消息超时与退回机制。自己封装一层抽象反而容易掩盖重试语义、丢消息或误设 MaxInFlight 导致堆积。
常见错误是把 nsq.Producer 当成单例全局复用——它本身线程安全，但若多个微服务实例共用同一 Producer 实例（比如注入到全局变量），会因共享连接状态引发竞争；正确做法是每个业务逻辑单元按需获取（或通过依赖注入容器管理生命周期）。
-
Producer初始化时必须显式调用ConnectToNSQD或ConnectToNSQLookupd，否则发消息会静默失败（无 panic，但err为 nil） - 若使用
nsqlookupd发现机制，务必确认nsqd启动时已正确注册：nsqd --broadcast-address=10.0.1.10 --lookupd-tcp-address=10.0.1.20:4160 -
Producer的SetLogger建议关掉，默认日志会刷屏；改用结构化日志（如zerolog）在回调中记录关键事件
消费端如何避免重复处理和消息丢失？
NSQ 不保证 exactly-once，只提供 at-least-once。真正可控的是「应用层幂等 + 消费确认时机」。核心不是靠 nsq.Consumer 的配置参数，而是你 handler.HandleMessage 里怎么写。
典型错误是：收到消息后立刻 message.Finish()，结果后续 DB 写入失败，消息就丢了；或者没做幂等校验，网络抖动导致同一条消息被投递两次，业务重复扣款。
- 必须在所有副作用（DB 写入、HTTP 调用等）成功后再调用
message.Finish()；失败则调用message.Requeue()或message.Touch()延长超时 - 每条消息的
message.ID是 NSQ 生成的 base32 字符串，可直接用作幂等 key；但注意它不唯一跨 topic，建议拼接topic+message.ID -
Consumer的MaxInFlight应 ≤ 单机并发处理能力（如 goroutine 数 × 平均处理耗时），否则大量消息 pending 在内存中，OOM 风险高
NSQ 集群模式下，如何做到无单点故障？
NSQ 本身无中心节点，但容错依赖两个组件协同：多个独立 nsqd 实例 + 至少两个 nsqlookupd 实例。真正的单点风险不在 NSQ，而在你的部署方式和客户端配置。
现象：服务启动后偶尔收不到消息，或某台 nsqd 挂了，部分 topic 就断连——大概率是客户端只连了一个 nsqlookupd 地址，或 nsqd 未配置多播地址。
-
nsq.Consumer初始化时，LookupdHTTPAddresses必须传入至少两个nsqlookupd的 HTTP 地址（如[]string{"http://l1:4161", "http://l2:4161"}），客户端会轮询探测 - 每个
nsqd必须设置唯一--node-id（默认用 hostname，但 K8s 下易冲突），并确保--broadcast-address可被其他 nsqd 和 consumer 正确解析 - topic 和 channel 不需要手动创建；首次 publish 或 subscribe 时自动创建，但要注意：channel 名含非法字符（如
/）会导致 lookupd 注册失败，日志只报invalid channel name，无堆栈
Go 服务启停时，NSQ 连接怎么平滑关闭？
直接杀进程会导致正在处理的消息被丢弃，nsqd 端残留 in_flight 状态；而 Go 的 os.Interrupt 信号捕获后，必须给 Consumer 和 Producer 显式调用 Stop()，并等待其完成内部清理。
最容易忽略的是：调用 consumer.Stop() 后，仍可能有 goroutine 在跑 HandleMessage —— 这些 handler 不会自动中断，得靠你代码里的上下文控制超时或主动 return。
- 在
main函数中监听os.Interrupt或syscall.SIGTERM，触发 shutdown 流程 -
consumer.Stop()返回后，应等待consumer.StoppedChan()关闭，表示所有连接已断开、goroutine 已退出 - 生产者发消息前加 context 控制超时：
producer.PublishAsync(topic, data, nil)不带超时，建议改用producer.Publish(topic, data)或自行包装带 timeout 的版本
NSQ 的容错能力藏在细节里：不是配几个节点就行，而是每个 nsqd 的磁盘队列路径是否独立、nsqlookupd 是否真跨 AZ 部署、consumer 的 HeartbeatInterval 是否小于 nsqd 的 --tcp-timeout……这些值一旦错位，集群看起来正常，实际早就在 silently 丢消息了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
