结论：用 go-redis 的 ZSet + Set + 原子命令组合更可靠高效，因 Redis 单命令天然原子、并发安全，而 Go 层遍历累加存在网络开销大、GC 压力高、结果不一致及无法保障原子性等问题；必须通过 Lua 脚本、合理过期策略与数据结构设计规避并发写入和统计漂移。
直接说结论：用 go-redis 的 ZSet + Set + 原子命令组合，比在 Go 层做聚合更可靠、更高效；但必须处理好并发写入和过期策略，否则统计结果会漂移。
为什么不用 Go 层遍历加总？
Redis 里存了几万条用户学习记录，如果每次统计都 MGET 拉到 Go 进程里循环累加，不仅网络开销大、GC 压力高，还容易因中间某次失败导致结果不一致。更关键的是——无法原子性保障。比如“今日新增学习时长”这类指标，多个请求同时写入时，靠 Go 层锁或 channel 协调，远不如 Redis 原生命令（如 INCRBY、ZADD）天然支持并发安全。
常见错误现象：
- 统计总数每天凌晨重置后，偶尔多出或少掉几条
- 热门课程排名突然跳变，排序依据的分数字段和实际 ZSet 成员不匹配
- 用户连续学习 3 天，但“连续打卡天数”字段隔天归零
- 根本原因往往是：Go 层读取 → 计算 → 写回，三步非原子，中间被其他写入覆盖
- 解决方案不是加锁，而是把计算逻辑下沉到 Redis 命令本身
- 例如“累计学习分钟数”直接用
INCRBY key delta，而不是先GET再SET
用 ZSet 实现带权重的实时排行榜
语言学习 App 常见需求：按“本周有效学习时长”给用户排榜。这里“有效”指单次学习 ≥5 分钟才算，且同一天只记一次最高值——这不能靠简单 INCR 实现，得组合使用 ZSet 和 Hash。
实操建议：
- 每次学习结束，先写 HSET user:{id} last_study_time {unix_ts} 和 HINCRBY user:{id} total_minutes {delta}
- 再用 ZADD weekly_rank {score} {user_id}，其中 {score} 是 Lua 脚本动态算出的“本周最高单日分钟数”
- 每日凌晨用 ZREMRANGEBYSCORE 清理上周数据，避免 ZSet 膨胀
容易踩的坑：
- 直接用 TIME 命令获取时间再拼字符串，时区错乱 → 改用 EXPIREAT 或服务端统一用 UTC 时间戳
- ZADD 时 score 类型传 float64，但 Redis 内部只保留 17 位精度 → 对毫秒级时间戳做除法取整（如 ts / 3600）再传
- 忘记给 ZSet 设置 TTL，长期运行后内存暴涨 → 在初始化时用 EXPIREAT 绑定过期时间，而非依赖被动淘汰
用 Set + Pipeline 避免重复统计
比如“今日完成语法练习的用户数”，要求去重统计。如果用 INCR 每次+1，同一用户多次提交就会重复计数。正确做法是：用 Set 记录今日已统计用户 ID，再用 SCARD 获取总数。
立即学习“go语言免费学习笔记（深入）”；
示例流程：pipeline := rdb.TxPipeline()pipeline.SAdd(ctx, "today_practice_users", userID)pipeline.SCard(ctx, "today_practice_users")_, err := pipeline.Exec(ctx)
注意点：
- 不要用 SISMEMBER 先查再 SADD，竞态条件会导致重复插入 → SADD 本身返回是否新增，足够判断
- SCARD 结果是 int64，Go 层接收时别误用 int（32 位系统可能溢出）
- Pipeline 不保证原子性，但能减少 RTT；若需强原子，改用 Lua 脚本封装 SADD + SCARD
事务不是万能的，慎用 MULTI/EXEC
看到“需要保证多个操作一起成功”，第一反应常是 MULTI + EXEC。但在统计场景中，它往往带来反效果：阻塞其他客户端、增加延迟、且不解决跨 key 一致性问题（比如更新用户 Hash 同时删 ZSet 成员）。
更实用的替代方案：
- 用单个 Lua 脚本封装多步逻辑，Redis 保证脚本内命令原子执行
- 把关联数据存在同一个 Hash 或 ZSet 里（例如把用户等级和当前积分都存在 user:{id} 中），避免跨 key 更新
- 对最终一致性可接受的指标（如“本月累计活跃天数”），用定时任务异步修正，而非强一致事务
性能影响：
- MULTI/EXEC 在高并发下会使连接池等待队列拉长，QPS 下降明显
- Lua 脚本执行期间会阻塞整个 Redis 实例（尤其复杂循环），所以脚本必须短小、无网络 IO、无 sleep
真正难的不是写对一条 ZADD，而是想清楚哪些状态必须强一致、哪些可以妥协，以及 Redis 的原子边界在哪——比如 ZINCRBY 对某个 member 的 score 是原子的，但没法同时保证它和另一个 key 的更新同步。这个边界感，得靠实际压测和日志比对才能建立起来。
