Redis PUB/SUB无法接收离线消息是设计使然，因其为纯内存广播机制，不持久化、不维护消费位点、不缓存历史消息，断连后重连仅接收新消息。
Redis 5.0 的 PUB/SUB 本质上没变，它还是那个不持久、无 ACK、不保证顺序的轻量机制——别指望靠它做可靠消息队列。
为什么 SUBSCRIBE 后收不到之前发的消息？
因为 PUB/SUB 完全内存态：消息只推给「当时已在线」的订阅者。发布前没人订阅，PUBLISH 返回值就是 0，消息直接丢弃，不会缓存。
常见错误现象：
- 先
PUBLISH再SUBSCRIBE，永远收不到第一条消息 - 客户端网络抖动断连后重连，中间漏掉所有广播
解决思路只有两个：
- 确保订阅逻辑在应用启动早期就执行（比如服务初始化阶段）
- 用
PSUBSCRIBE配合通配符（如log.*）时，注意模式匹配开销随订阅数线性增长，别滥用*匹配全部频道
PUBSUB NUMSUB 返回值为 0 却有客户端连着？
这是典型连接状态误判：Redis 只统计「处于 SUBSCRIBE/PSUBSCRIBE 命令阻塞状态」的客户端，不是所有 TCP 连接都算数。
容易踩的坑：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端执行了
SUBSCRIBE，但后续又发了其他命令（比如GET），Redis 会自动退出订阅状态，NUMSUB就不再计数 - 某些 Redis 客户端库（如旧版
redis-py）默认开启 pipeline 或自动重连，可能悄悄中断订阅上下文 -
PUBSUB CHANNELS列出的活跃频道，只反映当前有至少一个订阅者的频道，空频道不出现
想用通配符订阅但 PSUBSCRIBE 不生效？
PSUBSCRIBE 的模式匹配是服务端实现的，但规则很朴素：只支持 *（任意字符）和 ?（单字符），不支持正则语法，也不支持嵌套通配（如 user.*.update 中的双星号无效）。
使用场景限制：
- 模式必须以字母或数字开头，不能以
*开头（*.event合法，*全局匹配也合法，但**不合法） - 每个客户端最多维护一个 pattern 订阅链表，
PUNSUBSCRIBE必须指定原 pattern 字符串，模糊匹配不生效 -
PUBSUB NUMPAT返回的是「唯一 pattern 数量」，不是匹配到的频道数——哪怕 10 个客户端都订阅log.*，NUMPAT也只返回1
用 PUBLISH 发送大消息会卡住？
Redis 是单线程模型，PUBLISH 操作会同步遍历所有订阅该频道的客户端连接，挨个写 socket。如果某客户端网络慢、缓冲区满、或根本没读取（比如消费端阻塞），整个发布操作会被拖慢，甚至阻塞其他命令。
性能影响明显的情况：
- 单次
PUBLISH消息体超过几 KB，且订阅者数量 > 10 - 存在长期未读消息的慢消费者（比如日志归档客户端偶尔拉取）
- 混用
SUBSCRIBE和PSUBSCRIBE，导致同一消息被重复分发多次
实际建议：
- 消息体控制在 1KB 以内，结构尽量扁平（避免嵌套 JSON）
- 高频小消息场景，优先考虑
Stream+XADD+XREADGROUP，它支持 ACK、重试、消费者组偏移管理 - 真要用
PUB/SUB，就把订阅者做成短连接、快速处理、及时断开，别长期 hold 住连接
真正需要消息可靠性、重试、回溯能力时，Stream 才是 Redis 5.0+ 的正确答案；PUB/SUB 只适合「广播通知」「实时状态推送」这类允许丢失、不要求顺序的场景——它的简单，本身就是设计约束，不是缺陷。
