nsq生产者需手动重连，newproducer不自动恢复断连；必须监听err()通道捕获错误并重建实例；小规模直连nsqd，生产环境须用nsqlookupd实现服务发现；publishasync回调须轻量，避免阻塞；nsq为最终一致性，无严格顺序与exactly-once保障。
NSQ 生产者必须手动重连，nsq.NewProducer 不会自动恢复断连
很多 Go 项目上线后突然不发消息了，查日志发现没报错，其实是网络抖动或 nsqd 重启后，nsq.Producer 的 TCP 连接静默断开，但客户端毫无感知——go-nsq 默认不重连。
-
producer.Publish()在连接已断时仍可能返回nil错误（尤其在未启用config.OutputBufferSize或缓冲区满时） - 必须显式监听
producer.Err()通道，捕获"io: read/write timeout"、"connection refused"等错误 - 重连逻辑不能只
new一次，要重建nsq.Producer实例并重新调用.Connect() - 若使用
nsqlookupd，初始化nsq.NewProducer时需传入LookupAddresses，否则无法自动发现 topic 分片
示例关键片段：
cfg := nsq.NewConfig()
cfg.DialTimeout = 2 * time.Second
p, _ := nsq.NewProducer("127.0.0.1:4150", cfg)
go func() {
for err := range p.Err() {
log.Printf("Producer error: %v", err)
// 此处触发重建 producer（注意：p.Stop() 后不能再 Publish）
}
}()
消费者连 nsqlookupd 还是直连 nsqd？看部署规模
小团队本地验证或单机部署，直接 c.ConnectToNSQD("127.0.0.1:4150") 最省事；一旦上生产、多节点、要扩缩容，就必须走 nsqlookupd，否则每次增减 nsqd 都得改代码或配置。
- 直连
nsqd：无服务发现，channel消费负载无法自动均衡，适合调试或固定拓扑 - 连
nsqlookupd：依赖--lookupd-tcp-address和--lookupd-http-address启动参数，消费者通过 HTTP 获取 topic 分布，支持动态扩缩容 - 注意：
ConnectToNSQLookupd是异步注册，首次连接成功不代表立刻能收消息，需等 lookupd 同步完成（通常毫秒级）
PublishAsync 的回调函数里别做耗时操作
producer.PublishAsync() 看似高效，但如果回调里写数据库、发 HTTP 请求或加锁，会阻塞内部 goroutine，导致后续消息堆积、超时甚至丢弃。
- 回调只做轻量动作：打日志、更新内存计数器、触发告警信号
- 需要落库或通知下游？把消息 ID 或 payload 丢进本地 channel，另起 goroutine 处理
- 务必设
config.MaxInFlight = 100（默认 1），否则并发 publish 会被限流卡住 - 错误回调中不要 panic，
go-nsq不 recover，会导致整个 consumer goroutine 崩溃
Go 客户端不兼容 Kafka 那套“强一致”思维
NSQ 本质是最终一致性系统，没有 Kafka 的 acks=all、ISR、offset 提交语义。想靠它做金融级事务或严格顺序消费，会踩坑。
- 同一个
topic下，不同channel之间消息完全独立，无顺序保证 - 同一
channel内，NSQ 保证 at-least-once 投递，但不保证 exactly-once（需业务层幂等） - 没有 partition 概念，扩容靠新增
nsqd+nsqlookupd自动分摊，但 topic 数据不会自动迁移 - 别在生产环境关掉
nsqadmin——http://localhost:4171能直接看到每个 topic 的队列深度、失败率、连接数，比埋点还快
NSQ 的轻量和零依赖是优势，也是边界：它不替你管顺序、不替你存历史、不替你做跨机房同步。用之前先问一句——你真的需要这些吗？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
