redis订阅者断连后不补发消息是设计使然；go需显式调用pubsub.close()防goroutine泄漏，python需确保pubsub.close()执行，java需解耦连接与监听并手动重订阅，业务层须用list+pub/sub混合模式兜底。
订阅者异常断开后，Redis 不会自动清理订阅关系，也不补发断连期间的消息——这是设计使然，不是 bug。真正要解决的，是客户端资源泄漏、重复消费、以及业务消息丢失这三类问题。
Go 客户端（redis/v9）必须显式调用 PubSub.Close()
不调用 Close() 会导致 goroutine 持续阻塞在 Receive() 或 ReceiveContext() 上，无法退出，内存和连接句柄持续累积。
-
defer ps.Close()不能写在启动监听的 goroutine 内部——因为Receive()是阻塞调用，defer 根本不会执行 - 正确做法：用
context.WithCancel控制生命周期，把 ctx 传给ps.ReceiveContext(ctx)；收到ctx.Done()后，先调ps.Close()，再等待 goroutine 退出 - 忽略
redis.Nil或context.Canceled错误继续调ReceiveContext()，会 panic 或死循环
Python redis-py 的 pubsub.close() 容易被遗忘
直接丢弃 pubsub 对象而不调用 close()，其内部线程不会终止，回调引用无法释放，可能引发重复消费或内存泄漏。
- 常见错误写法：
ps = r.pubsub(); ps.subscribe(...); # 忘记 ps.close() - 安全写法：用
try/finally或with（需自行封装上下文管理器），确保ps.close()执行 - 信号中断场景（如 Ctrl+C）必须捕获并显式调用
ps.close()和r.connection_pool.disconnect()
Java Lettuce/Jedis 的连接与监听器解耦难
订阅连接（StatefulRedisPubSubConnection 或 JedisPubSub）和命令连接分离，但 close 逻辑常被混用或遗漏。
- Lettuce 中
autoReconnect=true不等于“自动恢复订阅”，重连后必须手动subscribe()，否则监听无效 - Jedis 的
JedisPubSub回调里不能直接 new Jedis 重连——会复用连接池中已失效的连接，触发RedisConnectionClosedException - 推荐：监听
onException或连接关闭事件 → 清理旧PubSubConnection→ 启动带退避的重试 → 成功后再subscribe
断连后消息丢失不可逆，得靠架构兜底
Pub/Sub 本身不存消息，断连即丢。想“不丢”，就得放弃纯 Pub/Sub，改用混合模式。
- 发布端必须严格按顺序：先
r.lpush('queue:order_events', data)，再r.publish('channel:order_updated', '1') - 订阅端启动时，先
lrange queue:order_events 0 -1补读，处理完再ltrim queue:order_events 0 -1清空 - List 长度不加限制会爆内存，建议配合
ltrim queue:order_events -1000或 TTL 清理策略
最常被忽略的点是：服务端 tcp-keepalive 和 timeout 没配，导致连接静默断开；而客户端又没心跳，结果既没及时发现断连，也没触发重连——最后归咎于“订阅不稳定”，其实根源在 TCP 层配置缺失。
