Redis键空间事件默认关闭，需配置notify-keyspace-events为KEA等组合才生效；事件频道名格式严格、无历史回放、过期事件延迟不可靠、断连事件丢失且无自动续订。
Redis 键空间事件默认是关闭的
Redis 启动后，notify-keyspace-events 配置项默认为空字符串，意味着所有键空间事件都被禁用。不手动开启，PSUBSCRIBE __keyspace@0__:* 之类操作根本收不到任何通知——不是代码写错了，是服务端压根没发。
- 必须通过
CONFIG SET notify-keyspace-events动态开启，或在redis.conf中配置（重启生效） - 常用组合是
KEA：K开启键空间（__keyspace@N__:），E开启键事件（__keyevent@N__:），A包含所有命令（如set、del、expire） - 别用
AKE或KA——顺序无关，但漏掉E就收不到del这类事件；漏掉K就无法按库订阅__keyspace@0__: - 注意：该配置不持久化，仅当前实例有效；若用容器或云 Redis，需确认启动参数或控制台是否允许修改
订阅时必须指定正确的频道名格式
键空间事件发布到两个固定前缀的频道：__keyspace@{db}__: 和 __keyevent@{db}__:。错一个字符（比如多空格、少下划线、库号写成 @1 却连的是 db 0）就收不到消息。
- db 号必须和目标键所在数据库一致，例如
SELECT 2后SET foo bar，事件只发往__keyspace@2__:foo，不是@0或@1 - 用
PSUBSCRIBE __keyspace@0__:*可匹配所有键，但通配符*是 Redis 的模式匹配，不是 shell 风格；不能写成__keyspace@0__:*a*去模糊匹配 key 名 - 客户端连接后才开始接收事件，之前发生的操作不会补推——没有“历史事件回放”机制
EXPIRE / TTL 触发的事件有延迟且不可靠
过期事件不是实时触发的：Redis 采用惰性删除 + 定期抽样清理，EXPIRE 设置后，实际 del 操作可能几秒甚至更久才发生，对应事件也随之延迟。更麻烦的是，如果 key 在过期前被访问过，惰性删除会立刻执行并发出事件；但如果一直没人碰，就只能等后台任务抽中——这导致行为不可预测。
- 不要依赖
__keyevent@0__:expired做精确时效控制（比如订单超时关单），它只适合“尽力通知”场景 -
TTL命令本身不触发事件，只有真正删除那一刻才发expired；而SET key val EX 5等价于SETEX，同样走这套延迟路径 - 若需强时效，得自己用
ZSET+zrangebyscore轮询，或改用 Redis Streams + 生产者主动写入
客户端断连后事件会丢失，无重连自动续订
Redis 发布/订阅是纯内存通道，没有消息持久化。一旦客户端网络中断、进程崩溃或未正确处理 PSUBSCRIBE 返回，断连期间所有事件永久消失。
-
PSUBSCRIBE不是幂等操作，重连后必须重新执行，不能假设上次订阅还有效 - 部分客户端库（如
redis-py）的pubsub对象不自动重连，需监听connection_error并手动调用psubscribe() - 别把键空间事件当消息队列用——它没有 ACK、没有消费位点、不保证至少一次投递
最常被忽略的一点：事件内容里只有 key 名和事件类型（如 set、del），不带值、不带时间戳、不带操作用户信息。想还原上下文，得自己在业务层配合记录日志或写入 Stream。
