ZAdd 必须显式构造 redis.Z 结构体，Score 为 float64（如 95.0），Member 强烈建议用 string；ZRevRange 索引需为 int64 类型，如 int64(-1)；更新分数依语义选 ZIncrBy（累加）或 ZAdd（覆盖）。
怎么用 ZAdd 正确写入带分数的成员？
别直接传整数或字符串当分数——ZAdd 要求你显式构造 redis.Z 结构体，否则会 panic 或静默失败。
-
Score必须是float64类型，哪怕你只想存整数积分，也得写成95.0，不能传95（int）或"95"（string） -
Member支持 string、int、甚至 struct，但生产环境强烈建议只用 string（比如用户 ID"uid:12345"），避免序列化歧义 - 重复调用
ZAdd同一个 member 会自动更新分数，不是报错，这是 Redis 的设计，别误以为“没生效”
示例：
err := rdb.ZAdd(ctx, "rank:weekly", &redis.Z{Score: 87.5, Member: "uid:789"}).Err()
if err != nil {
// 处理连接超时、key 类型错误等
}
为什么 ZRevRange 返回空，但 ZCard 显示有数据？
最常见原因是参数类型或范围写错：Redis 的索引是 long 类型，Go 客户端要求传 int64，不是 int；且 -1 表示“到最后”，但必须是 int64(-1)，不是字面量 -1（在 32 位系统或某些编译器下可能被截断）。
- 错误写法：
rdb.ZRevRange(ctx, "rank:weekly", 0, -1)——-1是 int，可能被当成4294967295（uint32 溢出） - 正确写法：
rdb.ZRevRange(ctx, "rank:weekly", 0, int64(-1)) - 如果只要前 10 名，用
0, 9，不是0, 10（左闭右闭，和 SQL 的LIMIT 10不同） - 要带分数一起返回，必须用
ZRevRangeWithScores，ZRevRange只返回 member 名字
更新分数该用 ZIncrBy 还是再调一次 ZAdd？
看场景。两者语义不同，混用容易导致逻辑错乱。
立即学习“go语言免费学习笔记（深入）”；
- 用
ZIncrBy：适合「累加行为」，比如点赞+1、阅读时长+30 秒。它是原子操作，线程安全，不会受并发写影响 - 用
ZAdd：适合「覆盖式更新」，比如用户最终得分由后台计算得出，要完全替换旧分。它不关心原值，直接覆盖 - 坑点：对同一个 member 先
ZIncrBy再ZAdd，后者会把增量结果整个覆盖掉，相当于白加了 - 性能上无差别，底层都是 O(log N)，但语义清晰比微小性能更重要
排行榜查不到最新数据？检查这三处缓存/延迟陷阱
Redis 本身不延迟，但你的代码可能卡在上下文、连接池或业务逻辑里。
-
ctx超时太短：比如设了context.WithTimeout(ctx, 100*time.Millisecond)，但网络抖动或 Redis 响应慢一点就直接返回空，而不是报错 - 没处理
nil错误：很多同学只判err != nil，但ZRevRangeWithScores成功时返回[]redis.Z，空榜就是空 slice，不是 error - 忘记清旧 key：测试时反复跑
ZAdd，但没DEL rank:weekly，导致历史脏数据干扰验证；上线后更要警惕 key 生命周期管理
真正难的不是命令怎么写，而是想清楚：这个排行榜是实时更新，还是准实时聚合？要不要加时间窗口？分数来源是否可信？这些决定了你用 ZIncrBy 还是批量 ZAdd，以及要不要加 Lua 脚本做原子校验。
