优雅关闭需满足三条件：停拉新消息、等当前任务完成、安全释放下游资源；close(ch)仅终止接收，不等待handler结束，易致goroutine泄漏；NSQ须用Stop()配合context超时；gqueue需Close()后显式等待worker退出。
直接关 channel 或调用 consumer.Close() 不等于优雅关闭——它只停了接收，没等正在处理的消息完成，也没释放依赖资源。真正的优雅关闭必须满足三个条件：停止拉取新消息、等待当前任务结束、安全释放下游连接（如 DB、Kafka、NSQ）。
为什么 close(ch) 不能用于消费者退出
关闭一个用于接收任务的 chan 只是让 range ch 循环退出，但无法感知当前正在执行的 handler 是否完成。常见错误是：close(taskCh) 后立刻 wg.Wait()，而 worker 中的 handleMessage() 还在阻塞（比如 DB 查询、HTTP 调用），导致 goroutine 泄漏或数据丢失。
- channel 关闭仅影响“读端”，不阻塞“写端”或运行中逻辑
- 若 worker 内部有重试、回调、异步写入，
close后这些操作可能仍在后台运行 - 没有超时控制时，
wg.Wait()可能永远卡住
NSQ 消费者怎么真正停掉
NSQ 的 consumer.Close() 是同步阻塞的，但它只保证停止拉取消息和断开 TCP 连接，不等待 HandleMessage 执行完毕。必须配合 context 和显式等待。
- 启动 consumer 前创建带超时的
context.WithTimeout，传给HandleMessage使用 - 调用
consumer.Stop()（非Close）触发 graceful shutdown 流程；Stop()会先禁用新消息分发，再等待所有活跃 handler 返回 - 务必检查
consumer.Stop()返回的 error，若超时需记录警告而非 panic - 若用了
MaxAttempts，确保失败消息已进入 DLQ 或被持久化，否则关闭时可能丢弃重试中消息
示例关键片段：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
err := consumer.Stop()
if err != nil && !errors.Is(err, context.DeadlineExceeded) {
log.Warn("NSQ consumer stop failed", "error", err)
}
基于 gqueue 的消费者如何安全退出
gqueue 自带 Close() 方法，但它的行为取决于工作模式：静态模式（有界）下 Close() 会立即关闭底层 channel；动态模式（无界）下则需等待链表清空 + 事件通道 drain 完成。不能假设它“自动等完所有消费”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 调用
queue.Close()后，仍需用sync.WaitGroup或context等待所有 worker goroutine 显式退出 - worker 中不应直接从
queue.C读取，而应封装一层带 cancel 支持的循环：select { case item := - 若 worker 内部调用了 DB 或 HTTP，需在 handler 中传递该
ctx并用于超时控制，否则ctx.Done()触发后仍可能卡在 I/O - 避免在
queue.Close()后继续调用queue.Push()，这会 panic（文档明确要求关闭后禁止写入）
最容易被忽略的资源泄漏点
消息消费者常依赖外部资源，关闭顺序错位会导致 panic 或连接泄漏。比如 Kafka 消费者交还分区失败，或 DB 连接池未设 SetMaxOpenConns(0) 就调 db.Close()。
- DB 连接池：先
db.SetMaxOpenConns(0)阻止新查询，等 3–5 秒，再db.Close()；若超时，记录 warning 但不要阻塞主流程 - Kafka：确保
RebalanceListener.OnRevoked已触发且返回 nil error，否则分区未交还，下次启动会触发UnknownMemberId - HTTP client：若消费者内部发起回调请求，需用带 timeout 的
http.Client，并在 shutdown ctx 里 cancel transport - 日志/监控客户端：像
prometheus.NewRegistry()或zap.Logger一般无需 close，但若用了异步写盘或网络上报，需查其文档是否提供Sync()或Close()
真正难的不是“怎么关”，而是“关到哪一层才算完”——每个依赖组件的关闭语义不同，必须逐层确认，不能靠单一 Close() 调用蒙混过关。
