直接用LRANGE+LPOP无法保证原子性，因为二者是两条独立命令，中间可能被其他客户端抢占导致重复消费或空指针；必须用Lua脚本封装为单次原子操作。
为什么直接用 LRANGE + LPOP 无法保证原子性？
因为 Redis 的多个命令默认不在同一个事务上下文中执行。比如先 LRANGE queue 0 0 查看队首，再 LPOP queue 出队，中间可能被其他客户端抢占——你看到的“待处理任务”实际已被别人取走，导致重复消费或空指针错误。
真正安全的做法是把“读+删”封装进一个 Lua 脚本里，靠 Redis 单线程执行特性实现原子性。
EVAL 脚本中如何安全地出队并返回值？
核心逻辑是：用 LRANGE 拿第一个元素，再用 LPOP 删除它，但必须确保两者动作不被中断。Lua 脚本里所有 Redis 命令都由服务端串行执行，天然原子。
示例脚本（出队一个任务，返回其内容或 nil）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
eval "local val = redis.call('lrange', KEYS[1], 0, 0) if #val == 0 then return nil else redis.call('lpop', KEYS[1]) return val[1] end" 1 queue
-
KEYS[1]是队列名，必须通过KEYS传入，不能硬编码或用ARGV - 用
#val == 0判断空队列，避免对空表调用val[1]报错 - 不要在脚本里做复杂逻辑（如重试、日志），否则阻塞主线程
用 redis.call 还是 redis.pcall？
选 redis.call。因为出队失败（比如 key 不存在）本身就是正常业务状态，应让脚本安静返回 nil，而不是抛异常中断整个 EVAL 流程。
redis.pcall 适合需要捕获底层错误（如语法错、内存满）的调试场景，生产脚本里反而会让简单逻辑变臃肿。
-
redis.call('lpop', KEYS[1])在空列表上返回nil，不会报错 - 若误写成
redis.call('nonexist_cmd', ...)，redis.call会直接报(error) ERR Error running script，而redis.pcall返回{err: "Unknown command..."} - 生产脚本应假设输入 key 合法，只处理业务空值，不兜底命令级异常
性能和并发要注意什么？
Lua 脚本在 Redis 中是同步执行的，单个脚本运行太久会卡住其他请求。这个出队脚本本身很轻量，但如果你在里面加了 for 循环重试、HTTP 调用或大数组遍历，就踩坑了。
- 别在脚本里解析 JSON 或做字符串拼接超过几百字符——Redis 的 Lua 解释器没优化这些
- 如果需要“取多个任务”，用
LRANGE+LTRIM组合比循环调用多次LPOP更高效 - 高并发下，脚本执行时间通常
最常被忽略的一点：脚本内容要缓存 SHA1 值复用 EVALSHA，否则每次传完整脚本字符串，网络和解析开销翻倍。
