PubSub.Close()不可省略，因其负责释放独占连接和阻塞goroutine；不调用会导致连接池耗尽、内存泄漏及goroutine悬挂。
PubSub对象不Close，连接池里的连接就永远卡住——不是Redis服务端没释放，而是客户端自己把连接“借走后忘了还”。
Go 的 redis/v9 中为什么 PubSub.Close() 不可省略
redis/v9 的 Subscribe() 返回一个 *redis.PubSub 实例，它底层会独占一个连接，并启动 goroutine 阻塞调用 Receive()。这个 goroutine 一旦启动，就不会自己退出；即使连接断开，它仍卡在 Receive() 上，持续持有连接资源。
-
defer pubsub.Close()写在 goroutine 里无效：因为Receive()是阻塞的，defer永远不会执行 - 不调
pubsub.Close()→ 连接不会归还给连接池 → 连接池逐渐耗尽 → 后续GetConnection()超时失败 - 哪怕你用的是单例客户端 + 连接池，每个
PubSub实例都对应一个“被长期占用”的连接，不是复用关系
Python redis-py 的 pubsub.close() 必须显式调用
redis-py 的 PubSub 对象内部维护了独立的监听线程（或 asyncio task），以及对连接的引用。如果只丢弃对象却不调 close()，线程不会自动终止，连接也不会释放。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 常见错误：订阅后直接 return 或让变量超出作用域，以为 GC 会清理 —— 实际上监听线程还在跑，连接持续占用
-
pubsub.close()会关闭内部连接、停止监听循环、清理回调引用；不调它，pubsub就是内存泄漏源 - 若用连接池（如
ConnectionPool），未 close 的 PubSub 会导致该连接无法归还，池中可用连接数缓慢下降
Java Lettuce 的 StatefulRedisPubSubConnection 怎么安全释放
Lettuce 的 PubSub 连接不是从连接池动态获取的，而是基于 Netty Channel 的长连接封装。它不走通用连接池路径，但依然需要手动管理生命周期。
- 必须调用
connection.close()，否则底层 Netty Channel 不会释放，相关 handler 和 listener 引用也无法 GC - 若配合
RedisMessageListenerContainer使用，注意它的stop()方法内部会调close()，但需确保调用时机——不能等 JVM 退出才触发 - 别在异常分支里漏掉
close()：比如重连逻辑中新建 connection 后，旧 connection 必须先close()再丢弃，否则双倍泄漏
所有语言共通的坑：重连时重复创建 PubSub 却不关旧的
生产环境必须处理网络抖动或 Redis 重启，但重连逻辑最容易犯错：新建 PubSub 实例前，没关掉旧的。
- 错误模式：
oldPubSub = client.Subscribe(...); ... if err != nil { oldPubSub.Close(); newPubSub = client.Subscribe(...) }—— 看似关了，但若Close()失败（比如连接已断），oldPubSub内部状态可能混乱，goroutine/线程仍在运行 - 稳妥做法：每次重连前，先判断
oldPubSub != nil并强制Close()，然后置为nil；再新建，避免悬挂引用 - 监控信号：观察客户端进程的 goroutine 数 / 线程数是否随重连次数线性增长，这是典型未清理的特征
真正难的不是写那行 Close()，而是在所有退出路径（正常结束、panic 恢复、context cancel、信号中断）里都确保它被执行。尤其当 PubSub 跨多个 goroutine 或模块传递时，谁负责关、什么时候关、关失败了怎么兜底——这些边界比语法本身更关键。
