收不到 redis pub/sub 消息主因是连接被断开，而非代码错误；需检查 client list 中 omem（超8mb可能断连）和 idle（远大于发送间隔说明消费卡住），并确认 client-output-buffer-limit pubsub 配置是否触发限流。
收不到 Redis Pub/Sub 消息，大概率不是代码写错了，而是连接、缓冲区或生命周期管理出了问题。直接看 client list 输出比反复改代码更有效。
检查 client list 中的 omem 和 idle
执行 redis-cli client list，重点关注订阅客户端那一行的两个字段：
-
omem：输出缓冲区内存占用（单位字节），超过 8MB 就可能被强制断连 -
idle：空闲秒数，如果远大于消息发送间隔（比如发消息是每秒一次，但idle=563），说明消费端卡住了
典型异常值：omem=12734654（≈12MB）、idle=563 —— 这说明服务端积压了大量未读消息，Redis 已按 client-output-buffer-limit pubsub 规则准备或已经关闭连接。
确认 client-output-buffer-limit pubsub 配置是否触发限流
Redis 默认对 Pub/Sub 客户端设了硬性缓冲限制：client-output-buffer-limit pubsub 32mb 8mb 60。意思是：
- 硬限制 32MB：达到即断连
- 软限制 8MB + 持续 60 秒：超时即断连
这个配置在高吞吐或消费慢的场景下极易触发。不要简单改成 0 0 0（官方明确不推荐），而应：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 调大软硬限（如
128mb 32mb 300）用于临时排查 - 根本解法是让消费逻辑异步化：用
pubsub.listen()只做快速收包，把message放进本地队列（如ConcurrentLinkedQueue），再由独立线程处理
验证订阅是否发生在发布之前，且频道名完全一致
Pub/Sub 是纯广播、无存储的即时通道。常见低级但高频的问题：
- 发布者脚本先跑完退出，订阅者才启动 → 消息已“飞走”，收不到
- 频道名大小写/空格/前缀不一致：比如发布用
alarm:order，订阅写成Alarm:order或alarm:order（末尾空格） - 使用了 pattern subscribe（
psubscribe）但没配对__keyspace@0__:*类型的事件，却误以为能收到普通PUBLISH消息
最稳验证方式：用两个 redis-cli 窗口手动操作 —— 先 subscribe test，再另起窗口 publish test "hi"，看是否立刻回显。
留意 notify-keyspace-events 是否干扰了你的监听逻辑
如果你监听的是键空间事件（如过期、删除），而不是自定义频道，那必须开启对应通知：
- 默认
notify-keyspace-events ""→ 所有键事件都被屏蔽 - 要接收
__keyevent@0__:expired，得配notify-keyspace-events Ex - 要接收
__keyspace@0__:mykey，得配notify-keyspace-events KE
注意：这个配置只影响键事件（KEYSPACE / KEYEVENT），和你用 publish mychan "msg" 发的普通消息无关。混淆这两类频道是调试时最常踩的坑。
真正难排查的点，往往藏在缓冲区膨胀和消费阻塞的组合里 —— 表面是“收不到”，实际是连接早被 Redis 主动踢掉，日志里甚至不报错。
