nsq.newproducer 连不上就 panic 是因 nsqd 未启动，需按序启动 nsqlookupd、nsqd、nsqadmin；publish 同步返回 error，publishasync 必须用 errchan 捕获错误；消费者应根据场景选 connecttonsqd 或 connecttonsqlookupd。
nsq.NewProducer 连不上就 panic，不是客户端 bug
Go 程序里一调 nsq.NewProducer("127.0.0.1:4150", config) 就报 connection refused 或直接 panic，不是你代码写错了，是 NSQD 根本没起来。NSQ 客户端不重试、不 fallback、不等服务就绪——它只管连，连不上就炸。
- 必须按顺序启动：先
nsqlookupd，再nsqd --lookupd-tcp-address=127.0.0.1:4160 --broadcast-address=127.0.0.1，最后nsqadmin -
--broadcast-address=127.0.0.1是本地调试铁律；不设或设成内网 IP（如192.168.x.x），消费者会连错地址 - 验证是否活：
curl -s http://localhost:4161/topics能返回 JSON，或打开http://localhost:4171看管理页不报错
Publish 和 PublishAsync 的错误处理逻辑完全不同
很多人以为 PublishAsync 是“快一点的 Publish”，其实它是完全不同的语义：一个同步阻塞等结果，一个异步甩出去就不管——除非你主动接住错误。
-
producer.Publish("topic", []byte("msg"))返回error，可直接 if 判断；适合关键日志、低频强一致场景 -
producer.PublishAsync("topic", []byte("msg"), nil)——第三个参数传nil，错误直接被吞掉，消息静默丢失 - 高频生产建议用
errChan := make(chan *nsq.Error, 100)，然后go func() { for range errChan { /* 处理 */ } }()单独消费，避免阻塞主流程
消费者连不上？大概率是 ConnectToNSQD 和 ConnectToNSQLookupd 混用了
Go 客户端这两个方法名字极具迷惑性：ConnectToNSQD 是直连单个 nsqd（适合本地调试），ConnectToNSQLookupd 才是走服务发现（生产环境必须）。
- 直连模式：消费者初始化后调
consumer.ConnectToNSQD("127.0.0.1:4150")，不用 nsqlookupd - 服务发现模式：必须初始化时传
LookupAddresses，例如nsq.NewConsumer("topic", "ch", cfg)后，再调consumer.ConnectToNSQLookupd("127.0.0.1:4161") - 漏掉
consumer.AddHandler(&MyHandler{})，消息来了也不会触发回调；HandleMessage返回nil才算成功消费，否则会重发
连接不能复用？其实是你没监听 Err channel 做重连
nsq.Producer 默认不自动重连，网络抖动或 nsqd 重启后，producer.Publish 可能一直返回 nil error 却发不出消息——因为底层 TCP 已断，但缓冲区还没刷完。
- 必须显式启动 goroutine 监听
producer.Err()，捕获"io: read/write timeout"、"use of closed network connection"等 - 重连不能只调
producer.Connect()，要重建nsq.Producer实例并重新.Connect() - 若用 nsqlookupd 发现 topic，初始化
nsq.NewProducer时就得传cfg并设置cfg.LookupAddresses = []string{"127.0.0.1:4160"}，否则发现机制压根不生效
NSQ 的轻量和简单是有代价的：它把连接管理、错误恢复、服务发现这些事全交给了客户端代码。最容易被忽略的是——PublishAsync 的错误回调不是可选的，而是唯一能感知失败的路径；而 ConnectToNSQLookupd 这个名字，真的很容易让人下意识当成“连到 lookupd 服务”，其实它连的是 lookupd 帮你找出来的所有 nsqd。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
