必须先开启Redis的notify-keyspace-events配置，设为"Ex"并重启或重写配置，否则无法收到__keyevent@0__:expired等消息；订阅需匹配实际DB编号，使用独立连接、recover防护及幂等处理。
必须先开启 Redis 的 notify-keyspace-events 配置
Redis 默认完全关闭键空间通知，不配就永远收不到 __keyevent@0__:expired 这类消息。只改代码没用。
要生效，必须在 redis.conf 中设置：
notify-keyspace-events "Ex"
其中 E 表示 keyevent 事件，x 表示 expired 类型；不要写成 AKE 或空值。改完记得 redis-cli config rewrite 或重启 Redis。
验证是否生效：
立即学习“go语言免费学习笔记（深入）”；
redis-cli config get notify-keyspace-events
返回值应为 1) "notify-keyspace-events" 2) "Ex"。否则后续所有监听逻辑都静默失败。
订阅频道名必须带 DB 编号，且不能用通配符混用
__keyevent@0__:expired 中的 0 是数据库编号，不是占位符。你连的是哪个 DB，就得订哪个 DB 的频道。
常见错误：
- 用
__keyevent@*__:expired—— Redis 不支持通配符订阅该类频道 - 连 DB 1 却订
__keyevent@0__:expired—— 永远收不到自己设的过期 key - 用
PSUBSCRIBE订__keyevent@0__:expired—— 这是普通SUBSCRIBE场景，不是模式匹配
正确写法（以 DB 0 为例）：
pubsub := rdb.Subscribe(ctx, "__keyevent@0__:expired")
监听 goroutine 必须独立连接，且带 recover + 重连
Pub/Sub 连接是阻塞式长连接，一旦断开或出错，ReceiveMessage() 会直接 panic 或返回 error，整个 goroutine 就死了，事件从此丢失。
关键防护点：
- 订阅必须用单独的
redis.Client实例，绝不能复用业务连接池 —— 否则一个断连拖垮全部读写 - goroutine 内部必须包
defer func(){...}()+recover() - 收到
redis.Nil或网络错误时，要主动pubsub.Close()，然后 sleep 几秒后重建连接和订阅 - 首次订阅前，建议先
rdb.ConfigSet(ctx, "notify-keyspace-events", "Ex").Err()做运行时兜底（但不能替代配置文件）
收到的 payload 是 key 名，不是 value，且不含 DB 信息
msg.Payload 就是纯字符串 key 名，比如 "user:123_delay"，不是 JSON，也不带数据库索引或类型前缀。
这意味着：
- 无法从 payload 判断它属于哪个 DB —— 全靠你订阅时指定的频道 DB 编号来对齐
- 无法知道它原本的 value 或 TTL —— 如需关联原始数据，得靠 key 命名规范（如
user:123_delay对应缓存 keyuser:123） - 高并发下可能重复收到同一 key 的 expired 事件（Redis 文档明确说明：不保证 exactly-once）—— 处理逻辑必须幂等，比如删缓存前先
Exists判断
典型处理片段：
if strings.HasPrefix(msg.Payload, "user:") && strings.HasSuffix(msg.Payload, "_delay") {
realKey := strings.TrimSuffix(msg.Payload, "_delay")
_ = rdb.Del(ctx, realKey).Err()
}
监听本身不难，难的是让这个“事件管道”在生产环境里持续、稳定、可追溯地跑下去。DB 编号错一位、连接没隔离、panic 没 recover —— 任何一个点断掉，延迟双删就退化成单删，缓存不一致风险立刻上升。 
