redis pub/sub 不支持消息过期机制，因其是纯内存即时广播通道，消息不存储、无ttl、不落盘；需改用set+expire、stream配合定时清理或zset实现带有效期的消息。
Redis 的 Pub/Sub 本身不支持消息过期机制——发布出去的消息一旦发出，就立刻广播给所有在线订阅者，没有 TTL、不存队列、不落盘、不重试，更不会自动清理。
为什么 PUB/SUB 无法让消息“过期”
Pub/Sub 是纯内存、无状态的即时广播通道。它不像 STREAM 或 LIST 那样保存消息实体，而是把消息当作“事件快照”直接推送给当前活跃连接。这意味着：
- 离线订阅者收不到任何历史消息（哪怕只断开 1 秒）
-
PUBLISH返回成功 ≠ 消息被消费，只是表示广播动作完成 - 你不能对某条已发布的消息调用
EXPIRE，因为它根本不存在于某个 key 下 - 没有任何配置项或命令能让频道里的某条消息“在 5 秒后自动失效”
想实现“带有效期的消息”，得换数据结构
如果业务需要消息具备生命周期控制（比如“这条通知 30 秒内有效，超时即丢弃”），必须放弃 PUB/SUB，改用支持显式过期的结构：
- 用
SET+EXPIRE：把消息内容存为 value，key 命名带唯一 ID，设置 TTL。消费者通过GET获取，失败即视为过期 - 用
STREAM+ 消费者组 + 外部定时清理：写入时记录时间戳，靠后台任务扫描并XTRIM超时条目（注意STREAM本身也不自动删消息） - 用
ZSET做延迟队列：score 存过期时间戳，用ZRANGEBYSCORE扫描到期项，处理完再ZREM - 别碰
LIST+BLPOP：它没有原生过期能力，得靠外部维护 TTL key 配合判断
notify-keyspace-events 不是消息过期，是 key 过期
很多人混淆了这个配置的作用。开启 notify-keyspace-events Ex 后，Redis 确实会发 __keyevent@0__:expired 事件，但它通知的是“某个 key 被删除了”，不是“某条 Pub/Sub 消息过期了”。典型误用场景：
- 你
PUBLISH channel "msg"→ 没有 key，不会触发任何事件 - 你
SET msg:123 "payload" EX 10→ 10 秒后 Redis 发送expired事件，但这是针对msg:123这个 key，不是那条“消息”本身 - 如果你没监听这个频道，或者监听了但没做对应处理，事件就丢了，且不可追溯
真正难缠的点在于：业务上所谓“消息过期”，往往混杂着语义层逻辑（比如“用户 60 秒内未确认则取消订单”），而 Redis 只管存储层的 key 生命周期。你需要自己把业务时间映射成 key 的 TTL，并确保监听、消费、清理三个环节全部串通，漏一环就会出现“通知发了但没人理”或“key 删了但下游还在等”的情况。
