Redis Sorted Set 的 score 必须为 float64 类型，Go 中需显式转换；ZRank/ZRevRank 返回零基索引而非名次；分页用 ZRevRange 时 stop 为 inclusive 索引；原子更新需 Lua 脚本；score 设计应适配业务排名逻辑。
Redis Sorted Set 的 score 类型必须是 float64
Go 语言里用 redis.Client 操作 Sorted Set 时，ZAdd 的 score 参数只能是 float64，不能传 int 或 string。常见错误是直接写 zadd("rank", 100, "user:1")，结果编译失败或运行 panic——因为 Go 不做隐式类型转换。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式转成
float64：比如float64(scoreInt)或math.Float64frombits(uint64(scoreInt))（仅当需要位级精确时） - 如果 score 来自 JSON 或 HTTP 查询参数，先用
strconv.ParseFloat解析，别用strconv.Atoi后再强转 - 注意浮点精度问题：排行榜若依赖严格整数排名（如并列同分），
score用100.0比100.00000000000001更稳妥；必要时可乘以 1000 存为毫分，避免小数误差
ZRank 和 ZRevRank 返回的是 int64 索引，不是 score
调用 ZRank 得到的是成员在升序排列中的**零基索引**（最小 score 排第 0），ZRevRank 是降序索引（最大 score 排第 0）。新手常误以为返回的是分数值或“第几名”，结果逻辑错乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 要获取“第几名”，需对
ZRevRank结果 +1（例如rank := revRank + 1），但注意nil返回表示 member 不存在 - 用
ZScore单独查分数，别试图从 rank 反推 score - 如果排行榜要支持并列（相同 score 视为同一名次），
ZRevRank不够用，得用ZCount统计 score ≥ 当前用户的数量：比如ZCount("rank", "(current_score", "+inf")配合ZScore手动算名次
批量查询 Top N 用 ZRevRange，但要注意 limit 和 offset
ZRevRange("rank", 0, 9, redis.ZRangeWithScores) 拿前 10 名没问题，但想分页查第 2 页（11–20 名）时，写成 10, 20 是错的——第二个参数是 inclusive end index，不是 count。实际应写 10, 19。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 分页计算公式：start = (page-1)*size，stop = start + size - 1
- 用
ZRevRangeByScore更灵活，尤其要按分数区间筛选时（如 “score >= 95” 的用户） - 大量数据下慎用大 offset：Redis 是线性扫描，
ZRevRange ... 10000 10009比0 9慢得多；高频分页建议用游标（ZRevRangeByScore+withscores记上一页末 score）
并发更新时 score 冲突需靠 Lua 脚本保证原子性
排行榜常有“用户得分增加”场景（如 +10 分），若先 ZScore 再 ZAdd，中间可能被其他请求覆盖。纯 Go 层无法保证原子性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
redis.Eval执行 Lua：local score = redis.call("ZSCORE", KEYS[1], ARGV[1])\nif not score then score = 0 end\nredis.call("ZADD", KEYS[1], tonumber(ARGV[2]) + tonumber(score), ARGV[1])\nreturn score - KEYS 和 ARGV 必须显式传入，不要拼接字符串防注入
- 注意 Lua 中
redis.call返回值类型：score 是 string，需tonumber()；空值返回nil，不能直接加法
Redis Sorted Set 的真正难点不在语法，而在 score 设计是否适配业务排名逻辑——比如时间戳+分数组合去重、用负数模拟降序、或引入二级排序字段。这些没法靠单个命令解决，得在写入前就规划好 score 的语义。
