XDEL仅删除Stream中的消息，不清理PEL；PEL中消息必须通过XACK显式确认才能移除，否则即使消费者离线、XTRIM执行或Stream被清理，消息仍长期驻留并占用内存。
消费者离线后Pending消息不自动释放
调用 XREADGROUP 拉取消息那一刻，Redis 就把消息塞进该消费者所属组的 Pending Entries List（PEL），不管消费者后续是卡住、崩溃还是直接断连。PEL 是独立于连接状态存在的内存结构，只要没收到对应 XACK，这条消息就永远留在里面——它不会因为客户端下线而自动清理，也不会被 XTRIM 删掉。
离线消费者让XPENDING查出大量idle超长的消息
执行 XPENDING mystream mygroup - + 10 时，你看到的不只是“未处理”，而是“已派发但无人响应”的真实快照。其中 idle 字段代表消息在 PEL 里躺了多久，一旦消费者离线，这个值会持续上涨；delivery-count 可能为 1，也可能因重试机制变成 2、3……但 Redis 不会主动重发或丢弃，全靠人工干预。
- 单个离线消费者可能让 PEL 占用几十 MB 内存（每条 pending 消息至少 32 字节元数据 + ID + 引用）
- 多个消费者轮流离线，容易触发“消息被重复分配”：同一个 ID 被分给不同 consumer，造成业务层重复处理或状态混乱
-
XPENDING返回的 consumer 名是字符串标识，不是连接句柄——你无法靠它判断对方是否还活着
为什么XCLAIM不能全自动兜底
XCLAIM 确实能把 idle 超时的消息转给其他在线 consumer，但它只是转移动作，不是修复逻辑：
- 必须显式指定目标 consumer 名，不能写
c2就完事，得确保c2真的存在且在线 - 转移后仍需该 consumer 主动
XACK，否则消息又卡在新 consumer 的 PEL 里 - 没有内置心跳或租约机制，Redis 不知道哪个 consumer “应该”持有哪条消息
- 若所有 consumer 都离线，
XCLAIM也无从下手，只能等人工介入或定时脚本轮询
真正可控的防线只有两道
PEL 爆满不是突发故障，而是长期缺乏监控和 ACK 约束的必然结果。靠加机器、扩消费者数量解决不了根本问题：
- 上线前必须强制约定：所有消费逻辑，无论成功失败，都要包裹
try/catch，失败不XACK，成功才调用XACK - 必须部署定时任务跑
XPENDING+XCLAIM组合，比如每 5 分钟扫一次 idle > 300000（5 分钟）的消息，并转给指定 backup consumer - 别依赖
BLOCK参数“省事”：阻塞读本身不防离线，反而会让崩溃后的 consumer 在重启前一直漏消息
最常被忽略的一点：PEL 的增长速度远快于 Stream 本身——一条消息在流里只存一份，在 PEL 里却可能被多个组、多个 consumer 同时引用。监控时一定要单独看 XPENDING 返回的总数，而不是只盯 XINFO STREAM 的 length。
