redis pub/sub不能构建多端同步聊天室，因其不存消息、不保送达、断连即丢；频道惰性创建，publish返回0说明无人订阅，需额外用set维护房间列表，断连消息无法补收。
Redis Pub/Sub 不能直接构建多端同步聊天室——它不存消息、不保送达、断连即丢，所谓“同步”只是所有在线客户端碰巧同时收到同一声广播。
为什么 SUBSCRIBE 收不到 PUBLISH 的消息
常见错误现象：SUBSCRIBE chat:room1 后死等无响应；PUBLISH chat:room1 "hi" 返回 (integer) 0；用 PUBSUB NUMSUB chat:room1 查到订阅数为 0。
根本原因不是配置错，而是 Redis 频道是惰性创建的：没有至少一个客户端成功完成 SUBSCRIBE，频道就不存在；PUBLISH 发向一个无人监听的频道，消息直接丢弃，不报错也不缓存。
- 检查是否在同一个 Redis 实例上操作（跨实例、跨集群不互通）
- 确认客户端连接未被防火墙或代理中断（
SUBSCRIBE是阻塞命令，连接一断就退订） - 频道名含空格或冒号以外的特殊字符（如
chat room1会被拆成两个参数，报ERR wrong number of arguments） - 区分大小写：
Chat:Room1和chat:room1是两个频道
如何让多个客户端“看到彼此发的消息”
Pub/Sub 本身只做广播，不识别用户、不解析内容、不控制流向。要实现“聊天感”，必须靠客户端和后端协同约定协议。
典型做法是：所有客户端统一订阅同一个频道（如 chat:general），后端服务作为中转桥接：
- 前端发消息 → WebSocket → 后端服务 → 封装为 JSON（含
from、text、ts）→PUBLISH chat:general "{...}" - 后端服务自己也
SUBSCRIBE chat:general→ 收到后通过 WebSocket 广播给所有在线前端连接 - 每个前端收到后，解析
data字段并追加到消息列表（注意过滤自己发的，避免回显）
关键点：SUBSCRIBE 连接只能收，不能发；PUBLISH 必须另起连接——Node.js 中常用两个 redis.createClient() 实例分别处理。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
PSUBSCRIBE 能不能自动发现新房间
不能。比如前端点“创建房间 A”，立刻 PSUBSCRIBE chat:A，但此时仍收不到任何消息。
因为 PSUBSCRIBE chat:A 只表示“我要听所有匹配 chat:A 的频道”，但 Redis 不维护“已存在频道列表”，也不会主动通知你“这个频道现在有消息了”。只有当有人对 chat:A 执行过 PUBLISH，该频道才被激活，PSUBSCRIBE 才能开始收。
-
PUBSUB CHANNELS chat:*查不到刚创建但没发过消息的房间 -
PUBSUB NUMSUB chat:A返回 0，不代表没人连，可能刚断开或订阅失败 - 想实现房间列表？必须额外用
SET chat:rooms或SMEMBERS维护元数据，和 Pub/Sub 完全解耦
连接断开后怎么补消息
没法补。这是最常被忽略的硬伤：SUBSCRIBE 连接一旦断开（网络抖动、页面刷新、进程重启），期间所有发布到该频道的消息全部丢失，Redis 不记录、不重放、不通知。
如果你需要断线续读、历史回溯、已读未读标记，Pub/Sub 就不该出现在生产架构里——改用 STREAM + XREADGROUP，配合消费者组和消息 ID 偏移量管理。
临时演示或内网联调可以接受；但只要用户真实使用，哪怕只有一条消息没收到，体验就断了。
