不需要。nsqd 可独立运行，不依赖 nsqlookupd；生产者直连 nsqd（如127.0.0.1:4150）即可发消息，nsqlookupd 仅用于多实例下的服务发现与动态拓扑管理。
nsqd 启动时必须连 nsqlookupd 才能自动发现 Topic 吗？
不需要。nsqd 可以独立运行，不依赖 nsqlookupd；直接用 TCP 地址（如 127.0.0.1:4150）连接生产者/消费者即可发消息。nsqlookupd 仅用于服务发现和动态拓扑管理——比如你有多个 nsqd 实例、想让客户端自动感知新增节点，才需要它。
常见错误现象：nsqadmin 页面看不到 Topic 或 Channel，或 ConnectToNSQLookupd 报 connection refused，往往是因为只起了 nsqd 没起 nsqlookupd，但其实这不影响基础消息收发。
- 纯单机开发调试：直接启动
nsqd即可，命令示例：nsqd --mem-queue-size=10000 --max-rdy-count=2500 - 需要自动注册/发现：必须同时运行
nsqlookupd，且nsqd启动时指定--lookupd-tcp-address -
nsqadmin依赖nsqlookupd的 HTTP 接口（默认:4161），否则无法拉取集群状态
go-nsq 生产者 Publish 失败但没报错，怎么回事？
最常见原因是生产者未调用 Stop() 就退出，导致底层连接被强制关闭，而 Publish() 是异步发送——它只把消息塞进内部 channel 就返回，不等真正写入网络。如果程序立刻结束，消息就丢了。
另一个隐蔽问题是 MaxInFlight 配置不当：当消费者 Rdy 数量为 0（比如处理太慢或没调 Finish()），nsqd 会拒绝接收新消息，但 Publish() 仍返回 nil（Go 客户端默认不校验响应）。
立即学习“go语言免费学习笔记（深入）”；
- 务必在程序退出前调用
producer.Stop()，等待所有待发消息 flush 完成 - 开启日志观察连接状态：
config.Verbose = true，看是否出现io: read/write timeout - 测试时加简单重试：
for i := 0; i - 避免盲目设高
MaxInFlight，它影响内存占用和消息堆积行为
Consumer 的 MessageHandler 里 panic 会导致消息丢失吗？
会。go-nsq 默认不 recover panic，一旦 handler 函数 panic，整个 goroutine 终止，当前消息既没 Finish() 也没 Requeue()，nsqd 会在超时后把它放回队列——但这是“至少一次”语义下的兜底，不是可靠重试。
更危险的是：panic 会中断 consumer 的主循环，后续消息不再投递，除非你手动重启 consumer 实例。
- 必须在
MessageHandler内部做defer func() { if r := recover(); r != nil { /* 记录日志 + Requeue */ } }() - 不要在 handler 里直接调用
os.Exit()或log.Fatal() - 推荐封装一层通用 wrapper：
func SafeHandler(h MessageHandler) nsq.Handler { return &safeHandler{h: h} }，统一 recover + requeue + metrics 上报 - 注意
msg.RequeueWithoutBackoff(true)和msg.Requeue(true)的区别：前者跳过退避延迟，适合瞬时失败（如 DB 连接闪断）
如何让 NSQ 支持真正的消息持久化？
NSQ 默认是内存队列，磁盘只是溢出缓冲。要实现类 Kafka 的强持久化，必须组合两个配置项：--mem-queue-size=0 + --disk-slow-write-timeout=2s，并确保 nsqd 有足够磁盘空间和 I/O 性能。
但要注意：设 --mem-queue-size=0 后，所有消息直写磁盘，吞吐量会明显下降（尤其小消息高频场景），且无法降级回内存模式——重启后仍走磁盘。
- 路径必须可写：
nsqd默认把数据存到/tmp/nsq，生产环境需显式指定--data-path=/var/lib/nsq - 磁盘写满时，
nsqd会拒绝新消息并返回DISCARD错误，客户端需处理该 case - 不要混淆
--max-req-timeout和磁盘超时：前者控制单条消息最大处理时间，后者控制磁盘写入容忍延迟 - 临时 Topic/Channel 不支持磁盘持久化，它们只存在内存中，订阅数归零即销毁
实际部署时，Topic 和 Channel 的生命周期管理、consumer 的优雅 shutdown、以及 nsqd 实例间的数据一致性，才是真正容易被忽略的复杂点。
