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
• 监听 __keyevent@0__:expired 做事后清理：需提前开启 notify-keyspace-events Ex，且客户端必须长连接，否则事件直接丢弃

别混淆“订阅连接超时”和“消息过期”

CONFIG SET timeout 60 设置的是客户端空闲断连阈值，和消息生命周期完全无关。它只影响订阅连接是否被服务器主动踢掉，不影响任何消息的时效性或存在性。

真正容易被忽略的点是：业务上要求“消息有效期”，本质是在要求“状态可查、可判定、可追溯”，而 PUB/SUB 天然不提供这些能力——它只负责“此刻广播”，剩下的全得你兜底。