ZREVRANK返回nil最常见的原因是key不存在或member不在ZSet中；它只对已存在的member生效，且返回0-based排名。
为什么ZREVRANK返回nil而不是数字？
最常见的情况是用户key不存在，或者该用户member根本不在ZSet里。Redis不会报错，而是静默返回nil——这容易让人误以为命令写错了。
- 先用
EXISTS确认key存在：EXISTS user:score - 再用
ZSCORE查用户分数是否真实存在：ZSCORE user:score alice，如果也返回nil，说明alice压根没进榜 -
ZREVRANK只对已存在的member生效；插入时漏掉ZADD、或用错key名（比如写成users:score），都会导致查不到
ZREVRANK和ZRANK到底该用哪个？
看榜单排序逻辑：你要的是“从高到低排第几”，就用ZREVRANK；“从低到低排第几”，才用ZRANK。别凭名字猜——REV就是reverse的意思，不是“推荐”或“重新”。
- 分数越高越靠前（如积分榜、热度榜）→ 用
ZREVRANK，排名从0开始（最高分是0） - 分数越低越靠前（如响应时间、延迟值）→ 用
ZRANK，最小延迟才是0 - 两者都不支持范围查询，也不能跳过重复分数；相同分数的
member按字典序排，但这个顺序不可控，别依赖它
在Lua脚本里调用ZREVRANK要注意什么？
直接redis.call('ZREVRANK', KEYS[1], ARGV[1])没问题，但返回值是nil或数字，不能直接拼字符串——Lua里nil和数字做..会报错。
- 务必判空：
local rank = redis.call('ZREVRANK', KEYS[1], ARGV[1]); return rank == nil and -1 or rank - 不要在脚本里对
rank做算术（比如加1转成“第1名”），除非你明确要显示“1-based”排名——Redis原生命令返回的永远是0-based索引 - 如果
key是动态生成的（比如按日期分表：user:score:202406），确保传入KEYS数组，别硬编码进脚本，否则集群模式下会失败
用ZREVRANK查排名慢吗？有替代方案吗？
单次ZREVRANK是O(log N)复杂度，只要ZSet不超千万级元素，基本感觉不到延迟。但如果你频繁查大量用户的排名（比如渲染百人榜单页），瓶颈往往不在命令本身，而在网络往返和客户端解析。
- 别循环调用
ZREVRANK查100个用户——改用ZUNIONSTORE+ZRANGE配合WITHSCORES批量拉数据再本地映射 - 如果只是想展示“当前用户排第几”，且并发量大，可以考虑冗余一个
HASH存user_id → rank，用ZREVRANK结果定时更新（比如每分钟一次），避免实时计算 -
ZREVRANK无法处理分数相同但需区分先后的场景（比如按插入时间）；这种需求得换结构，比如把时间戳拼进member名：alice|1717228800
nil返回值、0-based索引、相同分数的隐式排序，这三个地方最容易在上线后才发现不对劲。 
