__keyspace@0__:*只监听0号库，因@后的数字是硬编码数据库ID，Redis不支持@*通配所有DB；需分别订阅各库频道，或改用有效的全局监听方式__keyevent@*__:*。
为什么 __keyspace@0__:* 只监听 0 号库
Redis 的键空间事件频道名里带的 @0 不是占位符，而是硬编码的数据库编号。你写 __keyspace@0__:* ，Redis 就只往 0 号库的事件发消息；写 __keyspace@1__:* ，就只收 1 号库的。没有“通配所有 DB”的语法——@* 或 @all 都不合法，会直接被忽略。
psubscribe __keyspace@*__:* 实际上无效
很多文档写“用 __keyspace@*__:* 订阅所有库”，这是误导。Redis 不解析 * 作为数据库通配符，它只认具体数字。实测中：psubscribe __keyspace@*__:* 不报错，但完全收不到任何事件——因为 Redis 根本不会把事件发到这个不存在的频道。
- 真正能工作的模式只有
__keyspace@N__:*（N 是 0–15 的整数） - 若需监听多个库，必须分别调用
psubscribe多次，比如同时订阅__keyspace@0__:*和__keyspace@1__:* - 客户端需自行管理多个订阅连接，避免因一个库断连影响其他库监听
全局监听的可行方案：用 __keyevent@*__:* 替代
虽然键空间频道（keyspace）不支持 DB 通配，但键事件频道（keyevent）可以。Redis 允许用 @* 匹配任意数据库编号，所以 __keyevent@*__:* 是有效的全局监听方式。
- 它收到的消息格式是
PUBLISH __keyevent@0__:del mykey，你能从中提取出数据库号（0）和事件类型（del） - 相比
keyspace频道（PUBLISH __keyspace@0__:mykey del），它更适合做统一事件分发器 - 注意：必须在
notify-keyspace-events配置中启用E（键事件通知），例如设为KEA或至少Ex
配置与验证时容易漏掉的关键点
即使代码写了正确的 psubscribe，事件也常收不到，大概率卡在这几个环节：
-
CONFIG SET notify-keyspace-events必须包含对应字母：想收del事件要含K或A；想收expired要含E和x（即Ex） - 配置只对当前连接生效，重启 Redis 后失效；生产环境务必写进
redis.conf并重启服务 - Docker 容器里改了配置但没挂载
redis.conf，或挂载路径错误，导致实际运行的仍是默认空配置 - 用
redis-cli连上去执行CONFIG GET notify-keyspace-events，返回空字符串说明根本没开
最易被忽略的是：事件只在键**被实际删除时触发**，不是过期那一刻。比如 EXPIRE key 5 后立刻 DEL key，不会触发 expired 事件——因为键没等到自然过期就被手动删了。
