zadd 的 score 用 float64 是为支持小数精度（如活跃度、微秒时间戳、衰减系数），避免转 int 导致排序错乱；实操应直接存原始浮点值，展示时再格式化。
为什么 ZADD 的 score 用 float64 而不是 int
排行榜本质是按分数排序，但业务中分数常含小数（比如用户活跃度加权计算、时间戳微秒级精度、衰减系数乘积），ZADD 强制要求 score 是 float64，不是设计缺陷，而是预留扩展性。硬转成 int 再存会丢失精度，后续 ZREVRANGE 排序可能错乱。
实操建议：
- 直接用
float64存原始计算值，别四舍五入或截断 - 若必须整数显示（如前端展示“99分”），在应用层格式化，不改 Redis 中的 score
- 注意 Go 的
json.Unmarshal默认把数字转float64，如果从 HTTP 请求解析 score，别误以为是int类型再强转
ZREVRANGE 返回空结果的三个常见原因
ZREVRANGE 查不到数据，多数不是命令写错，而是底层数据状态不符预期。最常踩的坑有：
- key 不存在：Redis 对不存在的 sorted set 执行
ZREVRANGE返回空数组，不会报错 —— 检查是否漏了ZADD或 key 名拼写错误（比如rank:202405写成rank:20245） - score 全为 NaN 或 Inf：Go 里
math.NaN()或math.Inf(1)传给ZADD会导致该 member 被静默忽略，查不到也不报错 - offset + count 超出范围：比如总 10 条，却调
ZREVRANGE rank 50 60，返回空 —— 生产环境建议先用ZCARD获取总数再分页，或用ZREVRANGEBYSCORE配合边界条件
用 redigo / go-redis 做 ZADD 时如何避免并发覆盖
多个协程同时对同一 member 执行 ZADD，score 会被后写入的覆盖。这不是 Redis 问题，而是业务逻辑没控制好更新策略。
实操建议：
- 不要在应用层“读原值 → 算新值 → 写入”，这有竞态；改用 Lua 脚本原子执行，例如：
local cur = redis.call("ZSCORE", KEYS[1], ARGV[1])\nif not cur then\n redis.call("ZADD", KEYS[1], ARGV[2], ARGV[1])\nelse\n redis.call("ZADD", KEYS[1], tonumber(cur) + tonumber(ARGV[2]), ARGV[1])\nend - 如果只是“更高分才更新”，用
ZADD ... XX（仅更新已存在 member）+ZADD ... NX（仅新增）组合，但需两次请求，不如 Lua 干净 - go-redis 用户注意：
ZAdd方法第二个参数是*Z，其中Score字段必须显式赋值，别依赖零值
ZREVRANGE 分页性能拐点在哪
ZREVRANGE key 0 99 很快，但 ZREVRANGE key 10000 10099 会变慢 —— 因为 Redis 是跳表实现，offset 越大，内部遍历指针跳得越多。当排行榜规模超 10 万，偏移量 > 5000 就明显延迟。
替代方案：
- 用
ZREVRANGEBYSCORE key +inf -inf WITHSCORES LIMIT 0 100，配合上次返回的最小 score 做游标分页（避免 offset） - 高频访问的 Top N（如前 100 名）单独缓存一份
rank:top100，用EXPIRE定期刷新，降低主 sorted set 压力 - 如果业务允许弱一致性，考虑用
ZUNIONSTORE合并多维度 score 后再查，但要注意内存和执行时间开销
真正麻烦的是“查第 50001 名是谁”这种需求 —— 它天然低效，得提前想清楚是不是真需要，还是前端换个展示方式（比如只显示“排名 50000+”）。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
