ZREVRANGE 默认返回 member（如商品ID），非 score；需加 WITHSCORES 参数才同时返回 member 和 score，结果为交替格式。
用 ZREVRANGE 拿 TopN，但返回的是 score 还是 value？
直接说结论：ZREVRANGE 默认返回的是 member（也就是商品 ID 或名称），不是 score。很多人误以为它像 SQL 的 ORDER BY score DESC LIMIT N 那样“带分值一起出来”，其实不加参数只返 member。
常见错误现象：查出来一堆商品 ID，但不知道各自销量多少，还得额外 ZSCORE 一个个查 —— 性能掉得厉害。
- 要连 score 一起拿，必须显式加上
WITHSCORES参数 -
ZREVRANGE goods:hot 0 9 WITHSCORES才是正确姿势 - 返回结果是交替的：
["item_102", "248", "item_33", "211", ...]，注意解析时成对取值
ZREVRANGE 的索引是从 0 开始，但边界容易算错
Redis 的 range 索引是闭区间，ZREVRANGE key start stop 中的 start 和 stop 都包含在内。Top10 就是 0 9，不是 0 10 —— 后者会拿 11 个。
使用场景里最容易出问题的是动态分页或补位逻辑：比如想查“销量第 11 到 20 名”，写成 10 20 就多拿一个；想查“前 N 名”但 N 是变量，没做 N-1 转换也会越界。
- TopN 固定写法：
ZREVRANGE key 0 [N-1] - 如果 N 可能为 0，Redis 不报错但返回空数组，业务层得兜底判断
- 超范围（比如
stop大于实际元素数）不会报错，自动截断 —— 这点比 SQL 安全，但也容易掩盖数据异常
为什么不用 ZREVRANGEBYSCORE？它和 ZREVRANGE 本质不同
ZREVRANGE 是按**排名位置**取，ZREVRANGEBYSCORE 是按**分数范围**取。热销榜是典型“我要前 N 名”，不是“我要销量在 200~500 之间的商品”。
混淆这两者会导致严重偏差：当多个商品 score 相同时，ZSet 内部排序不稳定（相同 score 的 member 按字典序排），ZREVRANGEBYSCORE 可能漏掉或重复某些名次；而 ZREVRANGE 基于全局排名，结果确定。
- 只要业务语义是“销量最高前 N”，就该无条件选
ZREVRANGE -
ZREVRANGEBYSCORE更适合“查昨日销量 ≥ 100 的所有商品”这类场景 - score 设计建议：避免整数销量直接当 score，可乘以 1000 + 时间戳后缀防并列，但 TopN 查询本身不依赖这个优化
Python / Java 客户端拿到 WITHSCORES 结果后怎么安全解析？
Redis 协议返回的是扁平列表，客户端库（如 redis-py、Jedis）通常自动转成 list 或 tuple，但结构仍是 [member1, score1, member2, score2, ...]。直接遍历下标奇偶容易出错，尤其当 member 本身含数字或空格时。
性能影响不大，但解析逻辑写错会导致 score 错配到错误商品上，线上可能把销量最低的当成 Top1。
- redis-py 示例：
res = r.zrevrange("goods:hot", 0, 9, withscores=True)→ 返回[("item_a", 120.0), ("item_b", 115.0)]，自带解包，推荐用这个 - Jedis 需手动配对：
List<Object> raw = jedis.zrevrangeWithScores(...)，再用 for 循环每两步取一次 - 别用
zip(raw[::2], raw[1::2])—— 在大结果集上切片生成新列表，浪费内存
