Redis Sorted Set 用 ZADD 存用户排行榜时，应先在 Go 中计算好 float64 分数再传入，member 用 user:123 格式，重复 ZADD 自动更新；查排名用 ZREVRANK（注意返回索引需+1），分页查用 ZREVRANGE 并封装偏移处理，累加分数用 ZINCRBY 避免覆盖。
怎么用 ZADD 存带分数的用户数据
排行榜本质是按分数排序的动态列表，Redis 的 Sorted Set（有序集合）天然适合——每个成员关联一个 score，自动按分排序，插入、更新、查范围都快。
关键不是“存”，而是“怎么存才不翻车”：
-
ZADD是唯一入口，但别直接写死分数：用户积分可能来自多源头（点赞、打赏、活跃度），建议先在 Go 里算好float64分数再传，避免 Redis 端计算误差 - 成员名（
member）别用中文或空格，推荐用user:123这类结构化字符串，方便后续和用户表关联 - 重复
ZADD同一个member会自动更新分数，不用先ZREM再加——这是很多人多此一举踩的坑 - 如果分数可能为负或小数，确认业务逻辑是否允许；Sorted Set 支持任意
float64，但下游展示时注意精度截断（比如前端只显示整数分）
查排名为什么 ZRANK 和 ZREVRANK 总返回 -1
这是最常被忽略的兼容性问题：ZRANK 返回升序排名（分数最小排 0），ZREVRANK 才是降序（分数最高排 0）。排行榜几乎全要后者——但更隐蔽的坑是：
成员不存在时两者都返回 -1，而 Go 的 redis.ZRank 或 ZRevRank 方法返回的是 int64，不是错误。所以：
- 必须显式判断返回值是否为
-1，不能只看 err 是否为 nil - 用
ZREVRANK查“当前用户排第几”，但注意：它返回的是从 0 开始的索引，展示时得 +1 - 如果想查“前 10 名是谁”，别用
ZRANGE，要用ZREVRANGE，否则拿到的是垫底的 10 个
并发更新分数时怎么避免覆盖
多个 goroutine 同时调用 ZADD 更新同一用户分数，看似原子，但实际场景中分数常需累加（比如“用户 A 本次获得 5 分”），这时直接 ZADD 会覆盖旧分而非累加：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别在 Go 层读-改-写：竞态风险高，且网络往返增加延迟
- 改用 Redis 原生命令
ZINCRBY，它原子地对指定member的score做浮点加法，Go 客户端调用redis.ZIncrBy即可 -
ZINCRBY的增量参数必须是字符串（如"5"或"-2.5"），不是 float64，客户端库一般会自动转，但自定义封装时得留意类型 - 如果增量可能为 0，
ZINCRBY仍会执行（分数不变），但不会创建新成员——这点和ZADD行为一致
怎么高效分页查“第 100–110 名”
前端常要“加载更多”，但 ZREVRANGE 的 start 和 stop 是基于索引的，不是基于排名数字。比如要查“第 100 到 110 名”，对应索引是 99 到 109（0 起始）：
立即学习“go语言免费学习笔记（深入）”；
- 别手算偏移量：封装一个
GetRankRange(scoreKey string, startRank, endRank int) ([]redis.Z, error)，内部把startRank - 1当作start，endRank - 1当作stop - 注意边界：如果
endRank超过总人数，ZREVRANGE自动截断，不会报错，但返回结果少于预期——需要靠ZCARD预查总数做兜底提示 - 如果排行榜超大（百万级成员），
ZREVRANGE按索引查依然快，但别用ZRANGEBYSCORE配合分数范围查“中间段”，那会扫描整个区间，性能崩塌
真正难的不是命令怎么写，是分数设计是否经得起业务变化——比如初期用“总积分”当 score，后期要加权“7 日活跃分”，就得迁移到 Lua 脚本重算，而不是简单 ZINCRBY。
