ZADD 默认不覆盖已有成员分数，需加CH参数强制更新；ZREVRANGE为空多因score非double类型；分页错位源于同分member排序不稳定，应拼接时间戳或改用ZRANGEBYSCORE分页。
为什么 ZADD 不能直接覆盖旧分数？
很多开发者发现调用 ZADD 更新玩家分数后，排行榜顺序没变，甚至查不到最新值——根本原因是没理解 ZADD 的默认行为：它不会强制更新，而是仅当 member 不存在时才插入。想覆盖已有分数，必须显式带上 XX 或 NX 参数，但这两个是互斥条件。真正该用的是 CH（change）配合无条件写入：
-
ZADD leaderboard 1520 "player_42"—— 如果"player_42"已存在，分数不变 -
ZADD leaderboard 1520 "player_42" CH—— 强制更新，返回实际变动的 member 数量（0 或 1），CH还能让命令返回值更准确，便于判断是否真发生了变更 - 别用
NX做“更新”，它只在 member 不存在时才生效，本质是“插入锁”
ZREVRANGE 返回空列表？检查 score 类型和范围
调用 ZREVRANGE leaderboard 0 9 却拿不到数据，常见原因不是命令写错，而是 score 被存成了字符串或超出了整数精度。Redis ZSet 的 score 必须是 double 类型浮点数，但很多 SDK（比如某些 Python redis-py 版本）在传入 str 或 Decimal 时会静默失败或转成 0。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确保写入前 score 是原生
float或int，例如 Python 中用float(1520)而非"1520" - 用
ZSCORE leaderboard "player_42"手动验证单个 score 是否可读、是否为数字 - 如果分数带小数（如匹配胜率 98.7%），注意 Redis 对 double 的精度限制，避免用
0.9869999999999999这类 JS 浮点计算结果直传
高并发下 ZADD + ZREVRANGE 不一致？加个 ZCARD 验证长度
游戏高峰期，前端请求 ZREVRANGE 总是比预期少几条，但后台日志显示 ZADD 全部成功——这往往不是 Redis 问题，而是客户端缓存或 pipeline 误用导致的读写分离视图不一致。ZSet 本身是原子操作，但应用层可能：（1）多个进程/线程共用一个连接未做同步；（2）用了连接池却没控制 pipeline 顺序。
- 上线前用
ZCARD leaderboard对比写入总数与ZREVRANGE返回数量，若前者大得多，说明有写入被丢弃或 key 写错（比如写到了leaderboard:2024） - 避免在 pipeline 中混用写和读：
ZADD和ZREVRANGE放在同一 pipeline 可能因执行时机导致读不到刚写的 member - 对实时性要求极高的场景（如决赛倒计时排名），可加
WAIT 1 1000确保主从同步，但会增加延迟，慎用
用 ZREVRANGE 做分页时，为什么第 2 页开始数据重复或跳变？
ZREVRANGE leaderboard 10 19 看似是取第 2 页，但当多人分数相同时，Redis 不保证相同 score 的 member 的内部排序稳定性——也就是说，两次调用可能返回不同顺序的同分玩家，导致分页错位。
- 解决办法是引入二级排序字段，比如把 member 改成
"player_42|1623456789"（时间戳拼接），让相同分数下按插入时间降序，再用ZREVRANGE就稳定了 - 或者改用
ZRANGEBYSCORE+WITHSCORES配合游标分页，避免基于 index 的硬分页 - 别依赖
ZREVRANK做用户个人排名再算 offset，因为 rank 本身也受同分影响，且高并发下可能瞬时漂移
