zadd 一次写入即生效，score 必须为 double 类型，同分时按 member 字典序排序，需用“原始分×1e13+(1e13−毫秒时间戳)”构造复合 score 规避；zincrby 不适合主排行榜更新；自然周榜单应通过动态 key（如 leaderboard:2026w28）隔离周期。
ZADD 一次写入就生效，但要注意 score 类型和覆盖逻辑
Redis 的 ZADD 命令本身就是原子性的实时更新操作：只要 key 存在，新 member 插入或已有 member 的 score 更新都会立即反映在有序结构中，后续 ZREVRANGE、ZREVRANK 等查询立刻可见。
常见错误是误以为需要先 ZREM 再 ZADD ——完全没必要，ZADD 对已存在 member 会直接覆盖 score；也不用担心并发写入冲突，Redis 单线程模型天然保证顺序性。
-
ZADD leaderboard 1500 user:123：首次插入 -
ZADD leaderboard 1800 user:123：自动更新分数，排名实时重排 - score 必须是 double 类型，不能是字符串（如
"1500"），否则命令失败并报错ERR value is not a valid float - 如果业务要求“只增不减”，得靠应用层判断，Redis 本身不提供条件更新能力
同分时默认按字典序排，这不是你想要的“先到先得”
当多个用户 score 相同时，Redis ZSet 默认按 member 字符串的字典序升序排列（即 a 在 b 前），而排行榜通常希望“分数相同，先提交者排名更前”。这个行为无法通过配置关闭或修改。
所以必须主动规避字典序干扰，核心思路是：把时间信息编码进 score，让 score 不再重复。
- 不要用原始整数分数直接塞进
ZADD，比如ZADD lb 100 u1和ZADD lb 100 u2就会触发字典序排序 - 推荐做法：用
score * 1e13 + (1e13 - timestamp)构造复合 score，确保时间越早，数值越大（因倒序查榜用ZREVRANGE） - timestamp 必须统一为毫秒级 long，且要截断防止溢出（例如限制最大值为
9999999999999L） - Java 中用
jedis.zadd(key, combinedScore, member)，注意combinedScore是double，不是long（虽然计算过程用 long，但最终传 double）
ZINCRBY 适合积分累加类场景，但慎用于排行榜主 score
ZINCRBY 看起来很适合“用户每完成一次任务 +10 分”这种场景，但它只对单个 member 的 score 做原子加法，不解决同分排序问题 —— 如果多个用户初始 score 都是 0，第一次 ZINCRBY 后仍可能撞分。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
更关键的是：ZINCRBY 无法注入时间维度。它返回新 score，但你拿不到这次操作发生的时间戳，也就没法构造带时间的复合 score。
- 适合用在辅助计数器上，比如记录用户本周总动作次数：
ZINCRBY week_action:202628 user:123 1 - 不适合直接作为排行榜主 score 更新方式，除非你额外维护一个时间哈希表再做二次排序（性能差、不原子）
- 若坚持用
ZINCRBY，必须配合 Lua 脚本，在 incr 同时读取当前时间并重算复合 score，否则时间维度丢失
自然周榜单需动态 key，别硬编码周期逻辑到 score 里
按自然周划分榜单时，常见误区是试图把“第几周”信息塞进 score（比如用雪花算法拼接），这会导致 score 失去可比性 —— 不同周期的 score 数值范围不同，ZREVRANGE 查出来的根本不是当前周期数据。
正确做法是让 key 承担周期隔离职责，score 回归纯粹业务意义：
- key 命名示例：
leaderboard:2026W28（2026 年第 28 周），用LocalDateTime.now().get(WeekFields.ISO.weekOfYear())动态生成 - score 仍用复合方式：原始分 × 1e13 + (1e13 − 毫秒时间戳)，只服务于当前周期内的排序
- 清理过期 key：用
EXPIRE或定时任务DEL leaderboard:2026W27，避免 key 泛滥 - 不要在应用层缓存 key 名，每次操作都实时计算，防止跨周写错位置
复合 score 的精度和时间戳截断方式容易被忽略——13 位毫秒时间戳直接乘 1e13 会超出 double 精度，实际应先转成 long 再转 double，或改用整数型 score（Redis 7.0+ 支持 ZADD ... INCR 和整数 score，但兼容性需验证）。
