ZINCRBY 能直接更新用户积分排行，它原子性地对 ZSet 中成员分数做浮点数加法，存在则累加，不存在则以增量为初始分创建；支持负数扣分，但不防溢出，需业务层校验。
ZINCRBY 能不能直接更新用户积分排行
能，ZINCRBY 就是干这个的——它不是“插入新成员”或“覆盖旧分”，而是原子性地对 ZSet 中某个 member 的 score 做浮点数加法。只要用户 ID 已存在，分数就累加；不存在，就以给定增量为初始分创建新成员。
常见错误现象：ZINCRBY leaderboard 10 "uid:123" 执行后查不到数据？大概率是 key 名写错、Redis 连接非目标库、或该 key 被误删过（ZINCRBY 不会报错，但结果可能被写到空 key 上）。
- 必须确保 key 名一致（比如始终用
"user:leaderboard:weekly"，别一会儿用"leaderboard_weekly"） - score 支持小数，但别传字符串（如
"10.5"是 OK 的，"ten"会报(error) ERR value is not a valid float） - member 是字符串，二进制安全，但建议统一编码（避免 UTF-8 和 GBK 混用导致查不到）
为什么 ZINCRBY 比先 ZSCORE 再 ZADD 更可靠
因为它是原子操作。并发场景下，如果用“读分 → 算新分 → 写回”三步，两个请求同时读到 100 分，各自加 10，最终都写 110，实际应为 120。而 ZINCRBY 由 Redis 单线程执行，天然规避竞态。
使用场景：游戏金币变动、文章点赞数更新、实时排行榜积分累加等需要高并发写入且不容出错的计数类逻辑。
-
ZINCRBY的增量可以是负数（比如扣分：ZINCRBY leaderboard -5 "uid:123"） - 不支持整数溢出保护，超大浮点数（如
1e308）可能导致 score 显示为inf，影响ZRANGE排序 - 若需限制最高分，得靠业务层判断后截断，Redis 不提供“max score”参数
查排名时 ZRANK 和 ZREVRANK 的区别和坑
ZRANK 返回升序排名（分数最小的排 0），ZREVRANK 返回降序排名（分数最大的排 0）。排行榜几乎全用 ZREVRANK——毕竟用户要看“我排第几”，默认是按积分从高到低排。
容易踩的坑：ZRANK 和 ZREVRANK 对不存在的 member 都返回 nil（RESP2 下是 -1），不是报错。所以代码里必须显式判断返回值是否为空/负一，否则可能把“未上榜”当成“排名第 0”。
- 排名从 0 开始计数，前端显示时记得 +1（如
ZREVRANK leaderboard "uid:123"返回4，实际是第 5 名） - 分数相同时，Redis 按 member 字典序排序（
"uid:2"会排在"uid:10"前面），这不是 bug，是确定性行为，但业务上可能要避免依赖它 - 用
ZCOUNT统计某分数段人数时，注意区间是闭区间，ZCOUNT leaderboard 100 200包含 score=100 和 score=200 的成员
更新后怎么快速拿到 TOP N 和用户当前排名
别一次发两个命令再拼结果。用 pipeline 或 Lua 脚本合并操作，减少 RTT。尤其当用户刚加分、立刻想看“我升到第几名了+前五是谁”，两次独立请求可能因中间有别人加分而出现排名和榜单不一致。
一个轻量方案：用 Lua 把 ZINCRBY、ZREVRANK、ZRANGE 封在一个脚本里，保证原子读写。但注意 Lua 中不能用 ZRANGE ... WITHSCORES 后再做复杂格式转换，简单取 top5+当前 rank 就够用。
- 示例 Lua（Redis 6.0+）：
return {redis.call("ZINCRBY", KEYS[1], ARGV[1], ARGV[2]), redis.call("ZREVRANK", KEYS[1], ARGV[2]), redis.call("ZRANGE", KEYS[1], 0, 4, "WITHSCORES")} - 如果不用 Lua，至少保证两次命令走同一个连接（避免读到旧副本），并接受微小窗口期不一致
-
ZRANGE默认不带分数，要显示积分必须加WITHSCORES参数，漏掉就只拿到 ID 列表
