NSQ 是用于解耦、异步与削峰的架构组件，非语言级分布式能力；nsqd 必须显式配置 --broadcast-address 以确保网络可达；Publish 需手动重试，避免阻塞；MaxInFlight 应匹配 goroutine 并发数；关键消息需强制全落盘。
NSQ 不是分布式语言，Go 语言集成 NSQ 是为了解耦服务、异步处理和削峰填谷——它解决的是系统架构问题，不是语言本身的分布式能力。
nsqd 启动时必须指定 --broadcast-address
本地开发不加这个参数，消费者连不上 nsqd 是最常见报错。原因是 nsqd 默认用主机名注册到 nsqlookupd，而 Docker 容器或某些云环境里主机名无法被其他节点解析。
- 正确做法：启动时显式指定可访问的 IP 或域名，比如
nsqd --broadcast-address=127.0.0.1 --lookupd-tcp-address=127.0.0.1:4160 - 生产环境建议用内网 DNS 名（如
nsqd-01.internal），避免硬编码 IP - 如果只跑单机测试且不依赖
nsqlookupd，可直接用 TCP 地址连接127.0.0.1:4150，跳过 lookupd 发现流程
nsq.Producer.Publish 失败时不重试，需手动兜底
go-nsq 的 Publish 方法是同步调用，但底层 TCP 连接可能瞬断，错误返回后不会自动重发。你看到的 io: read/write timeout 或 connection refused 都属于这类场景。
- 不要假设一次
Publish调用就一定成功；业务关键消息应包装重试逻辑（例如指数退避 + 最大重试次数） - 避免在 HTTP handler 中直接阻塞调用
Publish，超时会拖垮整个请求；建议发到本地 channel 后由 goroutine 异步提交 -
MultiPublish批量发送虽提升吞吐，但失败时整批丢弃，不适合对单条消息可靠性要求高的场景
Consumer 的 MaxInFlight 配置直接影响吞吐与重复消费
MaxInFlight 控制客户端同一时间最多能“飞在空中”的未确认消息数。设太高，消费者崩溃会导致大量消息重回队列；设太低，吞吐上不去，还容易触发 nsqd 的 backoff 降速机制。
立即学习“go语言免费学习笔记（深入）”；
- 默认值是 1，适合强顺序或资源受限场景；一般建议从 25–100 开始压测调整
- 该值必须 ≤ 消费者处理函数的并发 goroutine 数，否则会卡住（
go-nsq内部用 channel 缓冲，满后不再拉新消息） - 消息处理中若 panic 且未 recover，
go-nsq会自动 requeue，但重试间隔由msg.Requeue(...)控制，不是立即重投
真正容易被忽略的是磁盘队列行为：NSQ 默认内存优先，内存满才刷盘；但一旦进程重启，未刷盘的消息就丢了。如果业务不能接受丢失，得配 --mem-queue-size=0 强制全落盘，代价是写入延迟上升 —— 这个权衡点不在代码里，而在启动参数中。
