decr不够用是因为它无法原子性地完成“检查+扣减+回滚”全流程：它不能前置校验库存是否充足，也不支持条件分支和失败后自动恢复原值；而lua脚本可在redis端原子执行判断、扣减、set回滚等多步逻辑，彻底规避竞态。
为什么直接用 DECR 不够用？
库存扣减看似简单，但真实场景中常需「检查 + 扣减 + 记录」原子执行，且失败时要恢复原值（回滚）。DECR 只能无条件减一，无法做前置校验（比如库存是否充足），更没法在减完发现超卖后自动加回去——它本身不支持条件分支和多步状态恢复。
而 Lua 脚本在 Redis 中是原子执行的，且可读写多个 key、做逻辑判断、返回明确结果。关键在于：**回滚不是靠 Redis 自动完成，而是由脚本显式控制——减之前先存旧值，失败就用 SET 恢复**。
EVAL 脚本里怎么安全实现“检查-扣减-回滚”？
核心思路是：用 GET 读当前库存 → 判断是否 ≥ 扣减量 → 是则 DECRBY 扣减 → 否则用 SET 把原始值写回去（即回滚）→ 最后统一返回结果码。不能依赖 INCR/DECR 的返回值做判断后再操作，那会破坏原子性。
示例脚本（扣减 quantity，key 为 stock:1001）：
if tonumber(redis.call('GET', KEYS[1])) >= tonumber(ARGV[1]) then
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1
else
redis.call('SET', KEYS[1], redis.call('GET', KEYS[1]))
return 0
end
注意：redis.call('GET', KEYS[1]) 被调用了两次，但没问题——因为整个脚本原子执行，中间值不会变；不过更稳妥写法是先 local stock = redis.call('GET', KEYS[1]) 缓存起来。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么不能在 Lua 里用 WATCH + MULTI？
WATCH 和事务（MULTI/EXEC）在 Lua 环境中不可用。Redis 明确禁止在 EVAL 中调用 WATCH，会直接报错 ERR WATCH inside Lua script not allowed。所以别想着“先 watch 再 multi”，这条路走不通。
常见误操作：
- 在脚本里写
redis.call('WATCH', KEYS[1])→ 运行时报错 - 试图用
redis.call('MULTI')开启事务 → 同样报错，且 Lua 中事务无意义（脚本本身就是原子的）
真正需要的不是事务，而是「单次原子决策 + 显式状态修复」，这正是 Lua 脚本能干净解决的。
实际部署时容易漏掉的三个细节
脚本逻辑对了，上线还可能翻车。这三个点常被忽略：
-
KEYS必须传入，不能硬编码 key 名——否则无法被 Redis cluster 路由，会报CROSSSLOT错误 - 库存初始值必须是数字字符串（如
"100"），不能是nil或"null"，否则tonumber(nil)得到nil，比较时出错；建议初始化时用SET stock:1001 "0" - 脚本返回值要用整数（
return 1），不要用字符串（return "ok"），客户端解析更稳定；若需返回剩余库存，改用return redis.call('GET', KEYS[1])
回滚的本质不是“撤销操作”，而是“用一次确定性的写覆盖掉错误状态”。只要脚本里每一步都基于当前已知值做判断和写入，就不怕并发干扰——这才是 Redis+Lua 处理这类问题的底层逻辑。
