redis zset的score必须为单个double类型浮点数，不可传json或字符串；多维度权重需通过整数错位相加（如quality×1000000+(ts%1000000)×100+hot）压缩为唯一标量，由客户端计算或lua脚本统一处理以避免跨语言浮点精度差异，并确保排序确定性。
score 必须是单个浮点数，别硬塞 JSON 或结构体
Redis ZSet 的 score 字段只接受 double 类型数值，传字符串（比如 "{'hot':10,'ts':1717023456}"）会直接报错 ERR value is not a valid float。这不是限制，而是设计使然：ZSet 底层依赖跳跃表排序，必须有确定、可比较的标量值。
常见错误是让客户端拼接字符串再转 float，比如 Python 里 float(f"{hot}.{ts}")——一旦 ts 超过 6 位或 hot 带小数，就会触发浮点精度截断，不同语言算出的 score 不一致，导致排序错乱。
- 正确做法：所有维度统一用整数运算压缩成一个 long 型数值，再转为 double 存入（如
quality * 1000000 + (ts % 1000000) * 100 + hot） - 必须由客户端计算并传入时间戳，Lua 脚本里不能调用
redis.call('TIME')—— score 必须确定，否则重放脚本结果不一致 - 避免用完整秒级时间戳（10 位）直接乘大系数，例如
ts * 1e6会轻易突破9007199254740992（2⁵³），引发精度丢失
用 Lua 脚本统一算分，防止多语言浮点差异
不同语言对浮点舍入、负数处理、科学计数法解析规则不同。Java 的 Math.round(-1.5) 是 -1，Python 的 round(-1.5) 是 -2，如果各自算 score 再 ZADD，同一组输入可能存进两个不同值，ZSet 排序就不可靠。
把加权逻辑下沉到 Redis 端，用 EVAL 执行 Lua 是唯一稳解：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
EVAL "return tonumber(ARGV[1]) * 1000000 + (tonumber(ARGV[2]) % 1000000) * 100 + tonumber(ARGV[3])" 0 8 1717023456 95
-
ARGV全是字符串，Lua 里必须显式tonumber()，否则+会变成字符串拼接 -
KEYS只放 key 名（如"leaderboard:week26"），用于沙箱校验；所有动态值（member、各维度原始值）走ARGV - 脚本内禁止耗时操作（如遍历大集合）、禁止网络调用、禁止非确定性函数（
math.random、os.time）
错位相加时，量级和顺序决定排序优先级
多维压缩的本质是「人为控制数字权重」：高位变化 1，比低位变化几百还影响大。比如 quality * 1000000 + (ts % 1000000) * 100 + hot 中，quality 改 1 → score 变 1000000，而 hot 满分 100 也才影响 100，排序时 quality 绝对主导。
- 优先级高的维度，分配更大系数（更高位），且系数之间不能有重叠：比如质量用
* 1e6，时间就只能用* 1e2，不能也用* 1e5，否则会干扰 - 时间戳建议取模（如
ts % 1000000），防溢出；若需长期有效，可用相对时间（如距基准日的天数）替代绝对时间戳 - 如果某维度可能为负（如惩罚分），要整体平移为正数再参与错位，否则符号位破坏排序逻辑
ZRANGE 等分排序不稳定，得靠 member 字典序 fallback
当多个 member 的 score 完全相等时，ZSet 返回顺序不保证稳定——底层跳跃表插入顺序受内存地址、随机层数影响，不是按插入时间或请求顺序。
这会导致排行榜前端刷新时名次“跳变”，用户看到自己从第 5 名突然变成第 7 名，实际分数没变。
- 强制唯一 fallback：把 member 改成
"uid:123:ts:1717023456"这种带时间戳的字符串，score 相同时自动按字典序排，结果可重现 - 慎用
ZRANGE做分页展示；改用ZREVRANGEBYSCORE+limit offset count，能绕过等分不确定性 - 真要强一致查排名+邻项，必须用 Lua 封装：先
ZREVRANK，再ZREVRANGE，两次操作原子执行，避免中间被并发写入干扰
真正麻烦的从来不是怎么拼 score，而是量级对齐时手抖少写一个零，或者时间戳忘了取模，导致某天凌晨所有排行榜集体错乱——这种问题不会报错，只会静默排序错误。
