XREADGROUP阻塞是正常设计行为，仅等待新消息而非pending消息；未初始化group会报NOGROUP错误，consumer名重复将导致消息重复或卡死PEL。
XREADGROUP 阻塞等待是设计行为，不是故障。它和 XREAD 一样默认非阻塞，但加了 block 参数才会真正阻塞；没加却“卡住”，大概率是参数写错了或消费者组状态异常。
为什么加了 block 却一直不返回新消息？
这是最常被误判为“卡死”的场景。根本原因在于：消费者组里没有未处理的、属于该消费者的 pending 消息，且 stream 中没有新消息到达，而你又设置了 block —— 它就会等下去，直到超时或有新消息。
-
XREADGROUP的阻塞逻辑只作用于“尚未被任何消费者读取的新消息”（即 stream 末尾之后的消息），不会去拉取其他消费者已读未确认（pending）的消息 - 如果想读 pending 消息，必须显式用
XCLAIM，不能靠XREADGROUP ... block - 注意
block 0表示无限等待，但 Redis 连接可能被中间网络设备或 proxy 断连（比如空闲超时），导致客户端收不到响应，看起来像“永远卡住”
消费者组初始化没做 XGROUP CREATE 会怎样？
直接执行 XREADGROUP GROUP group1 c1 STREAMS mq > 会报错：(error) NOGROUP No such key 'mq' or consumer group 'group1'。但很多人忽略这个错误，又在代码里静默吞掉异常，结果后续命令全失败，表面看就是“没反应”。
- 必须先确保 stream 存在（
XADD或自动创建），再执行XGROUP CREATE mq group1 $（$表示从最新开始消费） - 如果想从头消费，得用
0-0而不是0，XGROUP CREATE mq group1 0-0 - 重复执行
XGROUP CREATE会报错，生产环境建议包装成幂等操作（比如先EXISTS判断）
消费者名称（consumer name）重复导致消息“消失”？
同一个消费者组内，如果两个进程用了完全相同的 consumer name（比如都叫 c1），第二次连接会把第一次的 pending-list 强制接管，旧连接正在处理的消息会被标记为“已转交”，但没发通知——旧 consumer 可能还在处理，新 consumer 又读一遍，造成重复；或者旧 consumer 崩溃后，新 consumer 拿到 pending 消息但没 XACK，消息就一直卡在 PEL 里。
- consumer name 必须全局唯一，推荐用进程 ID + 启动时间戳拼接，例如
c1_23456_1734598234 - 不要硬编码 consumer name，尤其在容器或 K8s 环境下，实例重启后 name 复用风险极高
- 可通过
XINFO CONSUMERS mq group1查看当前所有 consumer 及其 pending 数量，快速定位冲突
真正容易被忽略的是：阻塞本身不可怕，可怕的是你以为它在等消息，其实它在等一个根本不存在的 stream 或 group；或者你依赖它自动兜底读 pending，但它压根不干这事。确认初始化、隔离 consumer name、分清 > 和 XCLAIM 的职责，比调大 timeout 更有效。
