Gin 框架不内置消息队列，集成 NSQ 需通过 go-nsq 手动对接；本地调试需确保 nsqd 正确启动并配置 --broadcast-address=127.0.0.1；Producer 应作为 Engine 字段管理并显式 Stop；Consumer 必须在 Gin 启动前单独协程运行且设合理 MaxInFlight。
Gin 框架本身不内置消息队列能力，集成 NSQ 必须靠 go-nsq 客户端手动对接；别指望 Gin 的中间件或路由能自动处理消息收发，它只管 HTTP 请求，NSQ 是独立的 TCP 协议通信。
启动 NSQ 服务前必须确认三件事
本地调试时，nsqd 启动失败是 Gin 程序连不上 NSQ 的最常见原因——不是代码问题，是环境没跑起来。
-
nsqlookupd和nsqadmin不是必需的：单机开发只需nsqd --mem-queue-size=10000，但若用了ConnectToNSQLookupd却没起nsqlookupd，会卡在连接超时 -
nsqd的--broadcast-address=127.0.0.1必须显式设置，否则消费者可能连到局域网 IP（如192.168.1.100:4150），Gin 运行在 localhost 就收不到消息 - 验证是否就绪：用
curl http://127.0.0.1:4151/topics能返回 JSON（哪怕空数组），说明nsqd已监听；返回connection refused就得先查进程和端口占用
Gin 启动时初始化 NSQ Producer 要避开两个坑
把 nsq.Producer 塞进 Gin 的 gin.Engine 或全局变量里很常见，但容易因生命周期管理不当导致消息静默丢失。
- 别在 HTTP handler 里临时
nsq.NewProducer：每次请求都建连接，短连接风暴会快速耗尽本地端口，且PublishAsync的消息可能还没发出去，goroutine 就被回收了 - 必须调
producer.Stop()：Gin 程序退出（比如 Ctrl+C）前，要显式触发Stop，否则PublishAsync缓冲区里的消息直接丢弃——Publish同步调用虽会返回 error，但阻塞主线程，不适合高并发 API - 建议封装成 Gin 的
Engine自定义字段：例如engine.Producer = producer，并在engine.Run()之后 deferproducer.Stop()
Consumer 不能直接挂进 Gin 的 goroutine
Gin 的 engine.Run() 是阻塞调用，你没法在它后面直接 consumer.ConnectToNSQD()；更危险的是，把 Consumer 启动逻辑塞进 HTTP handler，会导致每来一个请求就启一个 Consumer 实例，重复消费、资源泄漏。
- Consumer 必须在 Gin 启动前单独协程运行：
go func() { consumer.Listen() }()，且需确保consumer实例是单例 - Handler 内只做「触发」动作：比如收到 POST 请求后调
producer.Publish("order_created", payload)，让 NSQ 异步投递，别在 handler 里处理业务逻辑 - MessageHandler 中 panic 会中断整个 Consumer：必须包一层
defer func() { recover() }，并显式调m.Requeue()或打日志，否则消息卡住、后续消息停摆
NSQ 的 Topic/Channel 模型和 Gin 的 REST 路由完全无关，别试图用 URL path 映射 Channel；真正容易被忽略的是：MaxInFlight 设太高会让内存暴涨，设太低会导致吞吐骤降——它控制的是“同时发给 Consumer 的未确认消息数”，不是并发数，调优必须结合实际处理延迟测出来。
