NSQ线上静默失效主因是连接与配置误用：Producer须全局复用并显式Connect()，ConnectToNSQLookupd()才用于生产服务发现，地址须为TCP端口（4160），PublishAsync错误回调不可为空且需异步处理，消息可靠性依赖幂等设计而非NSQ自身。
Go 项目里用 NSQ，最常出问题的不是“不会写”，而是“写了但线上静默失效”——比如某天消息突然不发了，日志没报错，producer.Publish() 还是返回 nil；或者消费者连着 lookupd 却收不到一条消息，查配置全对，就是卡在那儿。
Producer 必须全局复用且显式 Connect()
每次 HTTP 请求都 nsq.NewProducer() 是典型反模式：连接数暴涨、端口耗尽、too many open files 错误频发。Producer 不是无状态工具函数，它内部持有一个长连接 + 缓冲队列 + goroutine 池。
-
nsq.NewProducer()后必须调p.Connect()，否则Publish()会阻塞或 panic（尤其在未设超时的情况下） - 初始化后立即监听
p.Err()通道，捕获"io: read/write timeout"、"connection refused"等错误，不能只靠Publish()返回值判断 - 重连不是
p.Connect()再试一次，而是要p.Stop()→ 新建nsq.Producer实例 →Connect()→ 重新监听Err()
ConnectToNSQD 和 ConnectToNSQLookupd 别用反
名字极具迷惑性：ConnectToNSQD() 是直连单个 nsqd（适合本地调试），ConnectToNSQLookupd() 才是走服务发现（生产必需）。传错地址或协议，消费者就永远“在线却失联”。
- 连
nsqlookupd时，地址必须是 TCP 端口（默认4160），不是 HTTP 端口（4161）；传"127.0.0.1:4161"就等于白连 - nsqd 启动时若加了
--broadcast-address=127.0.0.1，consumer 才能通过 lookupd 正确拿到本地可连地址；不设或设成内网 IP，本地调试必连不上 -
ConnectToNSQLookupd()返回nilerr ≠ 已注册成功，需等 lookupd 同步完成（毫秒级），首次消费前建议加短延时或轮询/nodes接口确认
PublishAsync 的错误回调别空着，也别干重活
PublishAsync() 不抛异常、不阻塞，但也不兜底——漏掉错误回调，等于把失败消息直接丢进黑洞；回调里做 DB 写入或 HTTP 调用，则会拖垮整个 producer 的发送流水线。
立即学习“go语言免费学习笔记（深入）”；
- 第三个参数不能传
nil，至少传一个带缓冲的 channel（如make(chan *nsq.Error, 100)），再起 goroutine 消费它 - 回调函数里只做三件事：打日志、更新内存计数器、发告警信号；落库/通知下游必须丢进本地
chan异步处理 - 高频场景务必设
config.MaxInFlight = 100（默认是 1），否则并发 publish 会被限流卡死
消息可靠性不靠 NSQ 自身，靠你设计幂等与降级
NSQ 没有 Kafka 那套 acks=all 或 offset 提交机制，它只保证“最终一致性”。网络抖动、nsqd 崩溃、磁盘满都可能导致消息丢失，而 Publish() 成功返回只代表写入 TCP 缓冲区成功。
-
msg.ID是唯一标识，Consumer 处理前必须校验是否已处理（比如 Redis SETNX 去重） - 别依赖
msg.Attempts做重试控制——默认最多 100 次，但指数退避到后期间隔极长，中间某次失败就停了 - 生产环境必须部署多个 nsqd + nsqlookupd，单点故障时 lookupd 仍可返回其他可用节点
真正难的从来不是写出能跑通的 demo，而是让 NSQ 在凌晨三点网络抖动时，依然不丢关键订单消息——这要求你亲手写重连、亲手压测重试逻辑、亲手验证幂等边界。所有“自动恢复”“强一致”的幻觉，都要在第一次线上断连时被亲手打碎。
