Redis Stream 不支持在Lua脚本中调用XACK等消费者组命令，因其被设计为仅限客户端直接调用；Lua应仅用于消费前的业务幂等校验，如用SISMEMBER+SADD原子检查消息ID是否已处理。
Redis Stream 本身已内置 XACK 和消费者组机制，**不需要、也不支持用 Lua 脚本实现“消息幂等确认”**。这是个常见误解——Lua 在 Stream 场景下无法替代原生命令，强行封装反而破坏可靠性。
为什么不能用 EVAL 包裹 XACK？
Redis 的 Lua 环境明确禁止调用阻塞命令和部分管理类命令，XACK 虽不阻塞，但属于「仅限客户端直接调用」的流专用命令。尝试在脚本中执行会直接报错：
ERR unknown command `xack` inside lua script
这不是版本问题，是 Redis 设计层面的硬性限制。所有 Stream 消费者组操作（XREADGROUP、XACK、XCLAIM、XDEL）都不可在 Lua 中调用。
真正该用 Lua 的地方：消费前的业务幂等校验
Stream 负责可靠投递和进度管理，但不负责业务层重复处理。你该用 Lua 的位置是：在调用 XREADGROUP 取出消息后、执行业务逻辑前，用原子脚本检查该消息是否已被处理过。典型场景包括：
- 防止同一条消息被多个消费者实例重复处理（比如集群扩缩容时）
- 避免因
XCLAIM抢占导致的二次消费 - 与数据库唯一约束配合，做前置快速拦截
示例脚本（校验并标记已处理）：
if redis.call('sismember', KEYS[1], ARGV[1]) == 1 then
return 0
else
redis.call('sadd', KEYS[1], ARGV[1])
return 1
end
调用方式：EVAL ... 1 order:acked:group1 1789086136869-0
注意：KEYS[1] 是按消费者组+业务类型隔离的集合名，不是全局 key；ARGV[1] 是消息 ID，必须完整传入（不能只传时间戳部分）。
Key 设计和 TTL 配合的坑
用 Set 存已处理 ID 看似简单，但容易踩三个实际问题：
- Stream 消息 ID 是毫秒级时间戳+序号，长期累积会导致 Set 膨胀，必须配 TTL —— 但 Redis Set 不支持 key 级 TTL，得用
EXPIRE单独设，这就引入非原子风险 - 更稳妥做法是用
HSET+ 过期字段，或直接依赖 Stream 自身的XTRIM或MAXLEN控制日志长度，再用外部存储（如 MySQL）存最终状态 - 如果业务要求“永久幂等”，Set 必须永不过期，但需定期
SCARD监控大小，避免内存失控
真正关键的不是“怎么写 Lua”，而是分清边界：Stream 管投递链路，Lua 管业务入口闸门。把 XACK 的职责交给客户端直调，把“这条消息我真没处理过”的判断留给 Lua，这才是稳定组合。
