ZADD 写入必须显式指定 score 参数，分数建议用 float64 类型并加前缀如 "uid:123"；查降序排名（如 TOP10）应使用 ZREVRANK 并对结果 +1，注意返回 -1 时用户未上榜。
用 ZADD 写入带分数的用户数据，别漏掉 score 参数
Redis 的 Sorted Set（有序集合）是实现排行榜的核心，靠 score 控制排序。写入时必须显式提供分数，不能只传成员名。常见错误是误当成普通 SET 使用，比如：ZADD leaderboard 100 "user:123" 看似正常，但若分数是浮点数（如活跃度、权重值），得确认 Go 客户端是否自动转成字符串——github.com/go-redis/redis/v9 会把 float64 正确序列化，而老版本 redigo 需手动 fmt.Sprintf("%f", score)，否则可能存成 0 或报错。
实操建议：
- 分数用
float64类型，避免整数溢出（比如用毫秒时间戳作分数时，int32 不够） - 用户 ID 建议加前缀（如
"uid:123"），避免和其它业务 key 冲突 - 批量写入优先用
ZADD多参数形式（ZADD leaderboard 85 "uid:101" 92 "uid:102"），比循环单条快 3–5 倍
查排名用 ZRANK 还是 ZREVRANK？看榜单是升序还是降序
默认排行榜按分数从高到低（降序），比如“积分最高 TOP10”，此时要用 ZREVRANK 查某用户的正向排名（第 1 名返回 0）。如果误用 ZRANK，得到的是升序排名（最低分排第 0），结果完全反了。Go 里调用时，redis.Client.ZRevRank(ctx, "leaderboard", "uid:101").Val() 返回的是从 0 开始的索引，要显示“第 X 名”需 +1。
注意边界：
- 用户不在榜上时，
ZREVRANK返回-1，必须检查，不能直接 +1 后展示 - 分数相同时，Redis 按字典序排成员名，所以
"uid:101"和"uid:2"同分时，"uid:101"排在"uid:2"前面（因为'1' ） - 想让同分用户排名一致（比如都算第 3 名），得在应用层做去重计数，Redis 原生命令不支持“并列排名”
ZRANGE 分页取 TOP N，小心 offset 超出范围导致空结果
取前 10 名：用 ZREVRANGE leaderboard 0 9 WITHSCORES（降序用 ZREVRANGE）。但做分页（如第 2 页，每页 10 条）写成 ZREVRANGE leaderboard 10 19 时，如果总人数不足 20，会返回空数组而非截断结果——这是 Redis 行为，不是客户端 bug。
安全做法：
- 先用
ZCARD leaderboard拿总数，再算实际end：min(offset + count - 1, total - 1) - 用
WITHSCORES选项一次拿到分数和 ID，避免额外ZSCORE查询 - 不要依赖
ZSCAN做排行榜遍历，它不保证顺序，且无法按分数范围精确切片
更新分数后排名没变？检查是否用了 ZINCRBY 而非重复 ZADD
用户积分变动时，应优先用 ZINCRBY 增量更新：ZINCRBY leaderboard 10 "uid:101"。如果用 ZADD 覆盖写入（ZADD leaderboard 110 "uid:101"），看似一样，但会触发 Redis 重新插入，当并发高时可能因执行顺序问题导致短暂排名错乱（尤其在 pipeline 中）。另外，ZINCRBY 对不存在的成员会自动初始化为指定增量值，而 ZADD 不会创建新成员除非显式提供分数。
容易被忽略的点：
-
ZINCRBY的增量必须是字符串格式数字（Go 客户端会自动转），但传"10.5"和10.5效果相同 - 分数更新后，排名不是实时“刷新”的，
ZREVRANK下次查询才反映新顺序，没有延迟或缓存机制 - 如果需要“更新分数 + 获取新排名”原子性，得用 Lua 脚本封装
ZINCRBY和ZREVRANK，单纯管道（pipeline）不保证原子
Redis Sorted Set 的排序逻辑很稳定，但排名计算本身不存状态，每次都是现场算的。这意味着你不能假设两次 ZREVRANK 调用之间排名不变——中间可能有别的客户端改了分数。真正难的不是怎么查，而是怎么在分布式写入下让排名感知保持一致。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
