XACK不是防重复开关，而是确认已处理的动作；它仅从pending list移除消息，不参与分发，需配合XPENDING、XCLAIM及业务幂等才能避免重复消费。
为什么XACK不是“防止重复”的开关，而是“确认已处理”的动作
很多人误以为调用 XACK 就能自动阻止其他消费者拿到同一条消息——其实不是。XACK 本身不参与消息分发，它只做一件事：把某条消息从消费者组的 pending list 中移除。真正决定“谁收到哪条消息”的，是 XREADGROUP 的分配逻辑和消费者组内部的 offset 管理。如果没调用 XACK，这条消息就一直留在 pending list 里，下次该消费者或别人用 XCLAIM 拿走它，就会造成重复处理。
必须在成功处理后、且仅一次调用XACK
调用时机错误是重复消费最常见的原因。常见错误包括：
- 在消息刚读出、还没解析/落库/调用下游接口前就调用
XACK—— 后续处理失败，消息已确认，彻底丢失 - 在异常分支（比如 catch 块）里漏掉
XACK，但主流程又调了一次 —— 导致重复确认，Redis 返回 (integer) 0，但业务逻辑可能已执行两遍 - 用错参数：把
group名写错、streamkey 拼错、或传入了不存在的 message ID ——XACK静默失败，pending list 不变，消息仍可被再次 claim
正确做法是：只在所有业务逻辑（含 DB 写入、HTTP 调用、幂等校验）全部成功后，再执行 XACK。例如：
XACK mystream mygroup 1620000000000-0 1620000000001-0
配合XPENDING和XCLAIM才能闭环处理失败场景
仅靠 XACK 无法解决消费者宕机导致的 pending 积压问题。必须搭配监控和兜底机制：
- 定期用
XPENDING mystream mygroup - + 10扫描空闲时间超长（比如 >300000ms）的消息 - 对超时消息，用
XCLAIM把它转移给健康消费者：XCLAIM mystream mygroup new-consumer 300000 1620000000000-0 - 注意：
XCLAIM后原消费者若恢复并尝试XACK已被 claim 的消息，Redis 会返回 (integer) 0，此时你的代码必须检查返回值，不能假设成功
消费者必须自己实现幂等，XACK不提供幂等性
XACK 只标记“这条消息我认领过、也处理完了”，它不管你的业务是否真的只执行了一次。网络分区、进程崩溃、重试逻辑 bug 都可能导致同一条消息被不同消费者先后处理。所以：
- 每条消息必须带业务唯一 ID（如订单号），不能依赖 Redis 自动生成的 ID
- 消费逻辑开头先查 DB 或 Redis 缓存，确认该业务 ID 是否已处理；若已存在，直接跳过后续逻辑
- 不要把幂等判断放在
XACK之后——那已经晚了，重复逻辑可能已触发
最危险的盲区是：以为加了 XACK 就万事大吉，结果既没监控 pending，也没做业务幂等，最后发现订单创建了两次、库存扣了两回。
