因为incr无法在单次操作中生成随机数并保证子红包和等于总额，且客户端循环调用会导致竞态与金额不一致；必须用lua脚本原子化完成检查、拆分、写入全过程。
为什么不能直接用 INCR 拆红包？
红包拆分本质是「把一个总金额随机切成 N 份」，但 Redis 原生命令无法在单次操作中既生成随机数、又保证所有子红包和等于总额。如果用客户端循环调用 INCRBY 或 SET 拆分，会丢失原子性：中间失败导致部分写入、金额对不上。更危险的是，多个客户端并发拆同一个红包时，GET + SET 类操作必然产生竞态——你读到的剩余金额，可能在你计算并写回前已被别人改掉。
EVAL 脚本里必须一次性完成拆分与初始化
拆红包不是“先算再存”，而是“边算边锁住 key”。推荐做法：用 Lua 脚本在服务端完成三件事——检查红包是否未拆、生成 N 个满足和为 total 的随机正整数、用 HSET 写入每个用户红包详情，并用 EXPIRE 设过期时间。关键点：
- 用
math.random()生成 N−1 个 [0,1) 随机数，排序后切分 [0,1] 区间，再线性映射到 [1, total]，确保每份 ≥1 分且和严格等于total - 红包 key 建议用
redpacket:12345，子项用哈希（HSET redpacket:12345 uid_123 88），避免大量 key 膨胀 - 脚本开头加
if redis.call("EXISTS", KEYS[1]) == 1 then return 0 end，防止重复拆分 - 务必在脚本末尾调用
redis.call("EXPIRE", KEYS[1], 3600)，否则哈希可能永久残留
示例片段（拆 10 个，总额 1000）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
local total = tonumber(ARGV[1])
local count = tonumber(ARGV[2])
local key = KEYS[1]
if redis.call("EXISTS", key) == 1 then return -1 end
local points = {}
for i = 1, count-1 do table.insert(points, math.random()) end
table.sort(points)
local last = 0
for i = 1, #points do
local part = math.floor((points[i] - last) * total)
if part <h3>抢红包必须用 <code>HINCRBY</code> + <code>HEXISTS</code> 组合判断</h3><p>“抢”不是读取再扣减，而是尝试对某个用户字段做原子增减，并确认该字段此前不存在。常见错误是先 <code>HEXISTS</code> 再 <code>HINCRBY</code>——两次命令之间有间隙，仍会超发。正确姿势：</p>
- 用
HINCRBY redpacket:12345 uid_456 0先“预占位”：若字段不存在，Redis 自动初始化为 0；若已存在，返回当前值 - 紧接着用
HGET redpacket:12345 uid_456读值，若为 "0"，说明是首次抢到，立刻HINCRBY redpacket:12345 uid_456 amount扣减对应份额 - 但更稳妥的是把整个逻辑收进 Lua：
EVAL "... HINCRBY ... HEXISTS ..." 1 redpacket:12345，用redis.call("HEXISTS", KEYS[1], ARGV[1])判断是否已抢过 - 注意：不能依赖
HLEN判断是否抢完，因为哈希里可能有初始化为 0 的占位字段；应额外用一个redpacket:12345:remain计数器，每次成功抢后DECR
实际部署时最易忽略的两个坑
一是 Lua 脚本里没做 math.randomseed(os.time()) ——Redis 的 Lua 沙箱默认 seed 固定，导致所有实例生成相同随机序列；必须在脚本开头显式重置，或改用 redis.call("TIME") 返回秒级时间戳作为 seed。二是没控制哈希字段名长度：uid_ 后接用户 ID 若是长字符串（如 UUID），会导致单个哈希膨胀严重，影响 HGETALL 性能；建议用短 ID 或哈希截断（如 sha1(uid)[0..7]）。
