zadd 的 score 不能用时间戳，因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑；应使用业务分数（如积分）并利用 zadd 覆盖更新、zincrby 原子累加、zrem 安全删除。
为什么 ZADD 的 score 不能用时间戳当排名依据
排行榜的核心是 score 可控、可比较、可重复更新。如果直接用 System.currentTimeMillis() 或 time.time() 作为 score，会导致：同一用户多次提交时 score 几乎相同，ZREVRANGE 返回顺序不稳定（Redis 不保证同分元素的内部排序）；更严重的是，时间戳天然递增，新上榜者永远排在老用户后面，违背“分数越高名次越靠前”的业务逻辑。
正确做法是把业务分数（如积分、点赞数、活跃度）直接设为 score。例如用户 A 当前积分 9850，执行：
ZADD leaderboard 9850 "user:A"后续积分变 9920，再执行一次同 key 同 member 的
ZADD，score 自动覆盖——这是 Redis ZSet 的原子更新特性，不用先 ZREM 再加。
ZREVRANGE 0 9 是取前十，但要注意 offset 和 count 的语义
ZREVRANGE 是按 score 从大到小返回，0 9 确实拿到第 1～10 名（0-indexed），但容易忽略两个边界情况：
- 当集合不足 10 个成员时，不会报错，只返回实际存在的成员，这点安全
- 如果需要带 score 一起返回，必须加
WITHSCORES参数，否则只返回 member 字符串：ZREVRANGE leaderboard 0 9 WITHSCORES
- 若排行榜要支持“查第 11～20 名”，别写成
11 20，得写10 19——因为 offset 是起始索引，count 是要取的数量
用户改名或删号时，ZREM 比重新构建更稳妥
member 是字符串，通常用用户 ID（如 "uid:12345"），不是昵称。一旦用户修改昵称，ZSet 里存的仍是原始 ID，不影响排名逻辑。只有在用户注销且需彻底移出榜单时，才调 ZREM：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
ZREM leaderboard "uid:12345"
有人想用 ZREMRANGEBYRANK 清空整个榜，但注意：它按当前排名删，不是按时间删；如果只是临时清榜（比如每日重置），更推荐 ZREMRANGEBYSCORE leaderboard -inf +inf 或直接 DEL leaderboard——后者更快，且避免残留 score 边界问题。
并发更新时 ZINCRBY 比 ZADD 更适合“+1”类操作
比如点赞数每点一次加 1，用 ZADD 需先查当前 score 再计算新值，中间有竞态。而 ZINCRBY 是原子的：
ZINCRBY leaderboard 1 "user:B"如果
"user:B" 不存在，就从 0 开始加，结果是 1；已存在则在原 score 上累加。这个命令底层不依赖客户端读-改-写，适合高并发计数场景。
注意：ZINCRBY 的 increment 必须是数字字符串（如 "1"、"-5"），不能是浮点精度太高的值（Redis score 内部是 double，但业务上建议控制在整数范围，避免浮点误差影响排名判断）。
"100" 和 100 在某些客户端表现不同），以及没加 WITHSCORES 导致前端拿不到分数只能显示空名次。
