Redis PUB/SUB不支持消息过期，因其是纯内存广播机制，消息不存储、无TTL、不落盘；需改用SET+EXPIRE、STREAM配合应用层判断或监听__keyevent@0__:expired事件实现带有效期的通知。
不支持。Redis 的 PUB/SUB 本身没有消息存储，也就谈不上为“某条消息”设置过期时间。
为什么 PUBLISH 的消息无法设 TTL
PUB/SUB 是纯内存广播机制：消息发出即投递，不写入任何 key，不落盘，不保留副本。一旦 PUBLISH 返回成功，它只表示“已推给当前在线订阅者”，之后这条消息就彻底消失，Redis 内部没有任何结构能让你对它调用 EXPIRE 或查询状态。
- 试图给频道名加
EX（比如SET news:channel "xxx" EX 30）和PUB/SUB无关，这只是在操作一个普通 key -
__keyevent@0__:expired监听的是 key 过期事件，不是“某次PUBLISH的内容过期” - 客户端断连 1 秒，期间所有发往该频道的消息永远丢失，无法补收
想实现“30 秒内有效的通知”，该用什么替代方案
必须放弃 PUB/SUB，改用带生命周期控制的数据结构：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
SET+EX：发送端SET notice:123 "payload" EX 30；消费端主动GET notice:123，返回nil即说明已失效 - 用
STREAM：写入时把过期 Unix 时间戳塞进消息体（如{"ts": 1748296946, "data": "..."}），消费端拉取后自行判断ts < time.time() - 监听
__keyevent@0__:expired做事后清理：需提前开启notify-keyspace-events Ex，且客户端必须长连接，否则事件直接丢弃
别混淆“订阅连接超时”和“消息过期”
CONFIG SET timeout 60 设置的是客户端空闲断连阈值，和消息生命周期完全无关。它只影响订阅连接是否被服务器主动踢掉，不影响任何消息的时效性或存在性。
真正容易被忽略的点是：业务上要求“消息有效期”，本质是在要求“状态可查、可判定、可追溯”，而 PUB/SUB 天然不提供这些能力——它只负责“此刻广播”，剩下的全得你兜底。
