因为redis.client.subscribe返回的*redis.pubsub实例的receive方法默认阻塞等待消息，若未配合context.withcancel控制超时或中断，且未显式调用close()释放连接，协程将永久挂起并导致goroutine和连接泄漏。
为什么 redis.Client.Subscribe 会卡住协程？
调用 redis.Client.Subscribe 后返回的 *redis.PubSub 实例，其 Receive 方法是阻塞的——它会一直等新消息或连接断开。如果你只在 for 循环里无条件调用 ps.Receive()，又没做退出控制，这个 goroutine 就永远不会结束，哪怕客户端已关闭或服务重启。
常见错误现象：go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=1 显示大量处于 runtime.gopark 状态的 goroutine，堆栈里含 github.com/go-redis/redis/v9.(*PubSub).Receive。
用 context.WithCancel 主动中断 Receive
redis/v9 的 PubSub.Receive 支持传入 context.Context，一旦 context 被 cancel，它会立即返回 context.Canceled 错误（而非继续等待）。这是最直接、最可控的退出方式。
实操建议：
- 在启动订阅 goroutine 前创建带 cancel 的 context：
ctx, cancel := context.WithCancel(context.Background()) - 把
ctx传给ps.Receive(ctx)，而不是裸调ps.Receive() - 在需要关闭时调用
cancel()，然后显式调用ps.Close()释放底层连接 - 注意：
ps.Close()不会自动 cancel context，必须手动调用cancel()才能让正在阻塞的Receive返回
别漏掉 ps.Close() 和错误检查
PubSub 底层持有 TCP 连接和读写 buffer，不调 ps.Close() 会导致连接泄漏，Redis 服务器端也会维持空闲连接，长期运行后可能触发 maxclients 限制。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
典型遗漏点：
- 只 cancel context，但忘记
ps.Close()→ 连接未释放 - 在
Receive返回错误后直接 return，没处理ps.Close()→ 协程退出但资源残留 - 误以为
ps.Close()会同步关闭所有 goroutine → 它只是关闭连接，阻塞中的Receive仍需靠 context cancel 唤醒
推荐模式：用 defer ps.Close() 包裹整个接收循环，并在循环外统一管理 context 生命周期。
如何安全地多路订阅并统一关闭？
如果同时监听多个 channel（比如 ps.Subscribe("ch1", "ch2")），不能为每个 channel 启一个 goroutine 再分别 cancel —— 这会放大 goroutine 数量且难以同步关闭。
正确做法是复用单个 PubSub 实例 + 单个接收 goroutine：
- 用
ps.Subscribe("ch1", "ch2", "ch3")一次性订阅多个 channel - 在一个 goroutine 中持续调
ps.Receive(ctx)，用 type switch 处理*redis.Message、*redis.Subscription等类型 - 关闭时只 cancel 一次 context + 调一次
ps.Close() - 避免用
ps.Ping()或轮询检测连接状态 —— 它们不解决阻塞问题，反而增加复杂度
真正容易被忽略的是：context cancel 和 ps.Close() 的调用顺序无关紧要，但两者缺一不可；漏掉任一环节，都会留下 goroutine 或连接泄漏的尾巴。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
