订阅者断开时未调用Close()会导致消息积压和资源泄漏；Redis不自动清理异常断开的订阅，客户端必须显式调用Close()释放goroutine、线程、回调引用及连接资源。
订阅者断开时未取消订阅导致消息积压
Redis 的发布订阅模式本身不维护客户端状态，SUBSCRIBE 后若客户端异常退出（如进程崩溃、网络中断），Redis 不会自动清理其订阅关系。虽然连接断开后服务端会自动释放该连接的订阅上下文，但若客户端是主动关闭前未调用 UNSUBSCRIBE 或 PUNSUBSCRIBE，在某些场景下（比如复用连接、使用连接池、或监听了多个频道后只退订部分）容易残留无效订阅逻辑，更关键的是——客户端自己持有的监听器、回调引用、goroutine/线程可能没被回收，造成内存泄漏或重复消费。
- Go 客户端（如
github.com/go-redis/redis/v9）中，Subscribe返回的*redis.PubSub对象必须显式调用Close()，否则底层 goroutine 会持续阻塞在Receive()上，无法退出 - Python 的
redis-py中，pubsub.subscribe()后若直接丢弃对象，且未调用pubsub.close()，其内部心跳线程和消息循环不会终止 - Java 的
Jedis或Lettuce同理：PubSubConnection或StatefulRedisPubSubConnection需手动close()，否则连接资源和监听器引用无法释放
Go 使用 redis/v9 时如何安全退出订阅
核心是确保 PubSub.Close() 被调用，且接收循环能响应关闭信号。不能依赖 defer 放在 goroutine 内部——因为 Receive() 是阻塞调用，defer 不会触发。
- 用
context.WithCancel控制生命周期，把ctx传给ReceiveContext（v9.0+ 推荐），而非原始Receive() - 在主流程中启动监听 goroutine，同时监听
ctx.Done()和pubsub.Channel()，收到取消信号后先pubsub.Close()，再等待 goroutine 退出 - 避免在
ReceiveContext返回 error 后还继续调用它；常见错误是忽略redis.Nil（表示连接已关）或context.Canceled，导致 panic 或死循环
// 示例：安全退出结构
ctx, cancel := context.WithCancel(context.Background())
ps := rdb.Subscribe(ctx, "channel:log")
defer ps.Close() // 确保最终执行
<p>go func() {
for {
msg, err := ps.ReceiveContext(ctx)
if err != nil {
if errors.Is(err, context.Canceled) || errors.Is(err, redis.Nil) {
return
}
log.Printf("receive err: %v", err)
continue
}
if m, ok := msg.(*redis.Message); ok {
handle(m.Payload)
}
}
}()</p><p>// ...业务逻辑...
cancel() // 触发退出
_ = ps.Close() // 显式关闭，清空内部 channel 和 goroutine
Python redis-py 中 pubsub.close() 必须显式调用
redis-py 的 PubSub 对象默认启用独立线程处理消息（threaded=True），这个线程不会随连接关闭而自动结束。不调用 close() 就直接丢弃对象，会导致后台线程持续运行、CPU 空转、以及无法复用连接。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 务必在退出前调用
pubsub.close()，它会停止监听线程、关闭内部队列、并标记为已关闭 - 如果用了
pubsub.subscribe(...)绑定了回调函数，这些回调引用会被保留在pubsub.listeners中，不 close 就无法释放 - 在
atexit或signal处理中注册close()是常见做法，但注意：SIGKILL 无法捕获，所以仍需配合超时和健康检查
# 示例：带信号处理的安全退出
import signal
import redis
<p>r = redis.Redis()
pubsub = r.pubsub()</p><p>def cleanup():
pubsub.close() # 关键！不能省略</p><p>signal.signal(signal.SIGTERM, lambda s, f: cleanup())
signal.signal(signal.SIGINT, lambda s, f: cleanup())</p><p>pubsub.subscribe('channel:alarm')
for msg in pubsub.listen(): # listen() 是生成器，内部含阻塞
if msg['type'] == 'message':
process(msg['data'])
为什么不用 PING/PONG 心跳来判断订阅是否有效
Redis 发布订阅通道本身不响应 PING，PubSub 连接是单向数据流，服务端不会向客户端发送心跳。所谓“心跳”其实是客户端库在控制连接层（如 TCP keepalive）或额外起 goroutine 定期发 PING 命令——但这跟订阅状态无关。即使 PING 成功，也不能说明该连接上的 SUBSCRIBE 还在生效，更不能替代 UNSUBSCRIBE 或 Close()。
-
UNSUBSCRIBE是向 Redis 发送指令，告知“我不再关心这些频道”，影响服务端的频道订阅计数（PUBSUB NUMSUB可查），但不是必须的——连接断开时服务端会自动清理 - 真正必须做的是客户端侧资源回收：关闭 goroutine/线程、释放回调引用、清空缓冲 channel、断开底层连接
- 混淆点在于：有些框架（如 Spring Data Redis）把
disconnect()和unsubscribe()分开暴露，让人误以为后者是“优雅退出的必要步骤”，其实对大多数场景，close()已隐含退订和连接释放
实际中最容易被忽略的是：客户端库的文档里往往把 Close() 写在示例末尾，但没强调它是唯一能终止监听循环的手段；而开发者习惯性地只关连接、不关 pubsub 实例，结果留下僵尸 goroutine 或线程，数小时后才发现内存缓慢上涨。
