需结合XINFO CONSUMERS与XINFO GROUPS判断Streams实时消费延迟：关注pel-count、pending数、idle值及last-delivered-id与流尾ID的字典序比较，避免误判离线或假死状态。
怎么看 Streams 的实时消费延迟
用 XINFO CONSUMERS 和 XINFO GROUPS 配合看，不是只查一个就能判断延迟。消费者组里 pending 数量高、idle 值大，说明消息卡住了；但得先确认是不是真卡——比如消费者进程挂了，还是只是处理慢。
-
XINFO CONSUMERS <stream> <group>显示每个消费者当前 pending 的消息数和最后空闲毫秒数（idle） -
XINFO GROUPS <stream>看整个组的pending总量、last-delivered-id（最新发给消费者的 ID），对比流尾部 ID 可估算积压量 - 注意：
idle是从上一次XCLAIM或成功XREADGROUP开始算的，不是从消息入队开始算
为什么 XINFO STREAM 返回的 length 和 card 不一致
因为 length 是当前未被任何消费者组标记为「已交付」的消息数量，而 STREAM LEN 或 XRANGE ... COUNT 查的是物理存在的条目数——如果启用了 MAXLEN 或 MINID 自动淘汰，历史消息可能已被删，但消费者组还记着旧 ID，导致 XINFO STREAM 的 length 小于实际插入过的总数。
-
XINFO STREAM <key>中的length是「当前可读」的消息数，受MAXLEN影响 -
card字段不存在于XINFO STREAM输出中——别和集合命令混淆；想统计总写入量，得靠监控或自己记 counter - 流被
XTRIM后，first-entry会变，但已分配给消费者组的 pending 消息若未确认，仍算在组的 pending 里，哪怕对应 entry 已被 trim 掉（这时XCLAIM会失败）
消费者不在线时，XINFO 能看到哪些残留信息
只要消费者组存在，就算所有消费者都断连了，XINFO CONSUMERS 仍会返回该消费者记录，但 idle 会持续增长，pending 不清零。这时候容易误判“还在工作”，其实只是没心跳也没清理。
- Redis 不自动删除离线消费者，必须手动
XGROUP DELCONSUMER -
XINFO GROUPS的pel-count（Pending Entries List）才是真实积压数，它包含所有已分发但未确认的消息，不管消费者是否在线 - 如果消费者用随机名（如 PID）反复重连，会不断堆积新 consumer 条目，
XINFO CONSUMERS结果越来越长，查起来变慢
用 XINFO 查消费情况时最常踩的三个坑
一是把 last-delivered-id 当成最新消息 ID——它只是组内最后一次分发的 ID，流尾部可能已有更新的；二是忽略 entries-added 和 recorded-first-entry 的差值，这个差值才反映实际积压范围；三是以为 pending 为 0 就代表没延迟，其实可能消费者根本没启动或没连上组。
- 比对延迟，正确姿势是：
XRANGE <stream> + - COUNT 1拿到最新 ID，再和last-delivered-id做字典序比较 -
entries-added是流创建以来总写入数，length是当前剩余数，二者差值 ≈ 被 trim 或被消费掉的数量 - 如果
XINFO CONSUMERS返回空数组，不代表没消费者——可能是名字输错，也可能是组刚创建还没分发过消息
流消费状态不是静态快照，是多个视角拼出来的动态图景。少看一个字段，就容易把「积压」当成「正常」，或者把「假死」当成「忙碌」。
