XDEL 对已消费消息无效，因其仅逻辑删除未被任何消费者组读取的消息；已入PEL的消息调用XDEL会静默返回0，必须用XACK释放再XTRIM裁剪。
Redis Streams 的 XDEL 不能真正“删除”已消费消息——它只标记为逻辑删除，且仅对未被任何消费者组读取过的消息有效。
为什么 XDEL 对已消费消息基本无效
Redis Streams 的设计决定了：一旦某条消息被某个消费者组通过 XREADGROUP 或 XCLAIM 读取过，该消息就进入了该组的 PEL（Pending Entries List）。此时调用 XDEL 不会从底层日志中移除它，Redis 会静默忽略——返回值是 0（表示“没删成”），但不会报错。
- 现象：
XDEL mystream 1612345678901-0返回(integer) 0，但消息仍存在于XPENDING中 - 根本原因：Streams 的持久化语义要求 PEL 中的消息必须可重试，物理删除会破坏消费者组的可靠性保证
- 适用场景：仅适用于刚写入、尚未被任何
GROUP消费的“冷消息”，比如误发的测试数据
真正清理已消费消息的唯一可靠方式：用 XACK + XTRIM
已消费消息的生命周期管理依赖两个动作配合：确认（XACK）释放 PEL 条目，再靠 XTRIM 控制整体长度。这不是“删除”，而是“让旧消息自然过期”。
-
XACK mystream mygroup 1612345678901-0：从 PEL 中移除该消息，使其不再参与重试 -
XTRIM mystream MAXLEN 1000：强制流最多保留最新 1000 条，超出部分（含已XACK的）被物理丢弃 - 注意：
XTRIM是 O(N) 操作，N 是被裁剪掉的消息数；高频写入时避免设过小的MAXLEN，否则频繁触发裁剪影响吞吐 - 若需按时间清理，可用
XTRIM mystream MINID 1612345678900-0，但需自己维护 ID 时间映射
误用 FLUSHDB 或 DEL 的后果
有人想“一劳永逸”清空整个 Stream，直接执行 DEL mystream 或 FLUSHDB。这看似干净，实则埋雷：
-
DEL mystream确实会删掉流，但所有关联的消费者组元数据（CONSUMERS、PEL）也一并消失——下次XREADGROUP会从头开始读，造成重复消费 -
FLUSHDB更危险：如果同一 DB 里还有其他关键数据（如用户 session、缓存配置），全盘清空等于服务雪崩 - 正确做法：先
XACK所有已处理消息，再XTRIM到安全水位，最后才考虑DEL（仅限开发/测试环境）
Streams 的“清理”本质是流控，不是文件删除。最常被忽略的一点：没有全局“回收站”机制，XACK 后消息是否立刻消失，取决于 XTRIM 策略是否已生效——中间存在窗口期，监控时要看 XINFO STREAM mystream 的 first-entry 和 last-entry 是否在预期范围内。
