不能直接用xtrim maxlen清理stream，因其按数量硬截断，不感知消费进度，易误删未被所有消费者组处理的消息；安全清理须基于所有组最小pending id的前一个id，即全局安全删除点。
为什么不能直接用 XTRIM MAXLEN 清理 Stream
直接执行 XTRIM mystream MAXLEN 1000 看似简单，但极大概率会误删尚未被所有消费者组处理的消息。Redis 不知道哪些消息“已安全过期”，它只按插入顺序硬截断——哪怕某个消费者组的 XPENDING 还卡在 ID 1717020000000-0，而流里最老消息是 1716950000000-0，这中间的 70 万条全被砍掉，那个落后的组就永远收不到它们了。
根本问题在于：MAXLEN 是纯长度控制，不感知消费进度；而“已被所有消费者处理”的边界，必须由所有消费者组的最小 pending ID 决定。
如何定位全局安全删除点（Safe Trim Point）
安全删除点 = 所有消费者组中「最小 pending ID」的前一个 ID。这个 ID 之后的所有消息，才真正可被认定为“全部组都确认过了”。
- 对每个消费者组执行
XPENDING mystream mygroup - + 1，取返回结果中的第一个 ID（即该组最老 pending 消息 ID） - 把所有组返回的 pending ID 拿出来比较，找出最小的那个，比如
1717020000000-0 - 把这个 ID 减一：得到
1717019999999-9999（手动减需注意序列号溢出），或更稳妥地用~前缀让 Redis 自动找边界
最终安全 ID 就是 ~1717020000000-0 —— Redis 会自动保留所有 >= 该 ID 的消息，等价于“删除所有
用 XTRIM MINID ~xxx 安全清理（Redis 6.2+）
Redis 6.2 起支持 MINID 模式，配合 ~ 前缀可精准锚定安全边界：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
XTRIM mystream MINID ~1717020000000-0
这条命令含义是：“保留所有 ID ≥ 1717020000000-0 的消息”，即自动删掉所有更老的。相比 MAXLEN，它不依赖数量估算，完全基于实际消费水位。
注意事项：
- 必须用
~前缀，否则MINID 1717020000000-0是“严格大于等于”，可能多留一条不该留的 - 如果某个组还没任何 pending 消息（
XPENDING返回空），它的隐含“已读到末尾”，不影响最小值计算；但若所有组都为空，说明整条流都已处理完，可放心XTRIM mystream MINID ~0-0 - 生产环境建议加
LIMIT防止单次操作阻塞太久：XTRIM mystream MINID ~1717020000000-0 LIMIT 1000
兼容旧版 Redis（
低于 6.2 的版本不支持 MINID，只能靠 XRANGE + XDEL 组合模拟，但风险高、性能差，仅作应急：
- 先用
XRANGE mystream - + COUNT 1获取当前最老消息 ID - 再查所有组最小 pending ID，设为
safe_id - 若
最老ID ，说明有消息可删，但无法原子删除区间——只能用 <code>XDEL逐条删，且要避开safe_id及之后 - 实际中强烈建议升级到 6.2+，否则长期靠脚本轮询 +
XDEL容易漏删或误删，且XDEL对大 Stream 性能开销显著
真正难的不是命令怎么写，而是持续跟踪所有消费者组的 pending 水位，并在每次 trim 前重新计算——这个逻辑必须嵌入你的运维脚本或监控告警中，不能当成一次性手工操作。
