Redis ZSet 在 score 相同时按 member 二进制字典序稳定升序排列，不会混乱；常见“不一致”源于客户端缓存、误判或 UTF-8 字节序与语义序混淆；验证可用 ZADD/ ZRANGE 最小闭环测试；业务需时间序时应将时间编码进 score。
Redis ZSet 在 score 相同时**不会排序混乱**，它始终按 member 的二进制字典序（lexicographical order）升序排列，这个行为是确定、稳定、可预测的。所谓“混乱”，往往源于对规则理解偏差或误用场景。
为什么 score 相同的 ZSet 排序看起来“不一致”？
常见错误现象包括：
- 同一组
score和member，在不同客户端或多次ZRANGE中返回顺序“有时变”——实际是客户端缓存、网络分包、或未加WITHSCORES导致误判； - 插入顺序不同但
member相同，结果却一样——这恰恰证明排序没乱，因为ZADD会覆盖而非新增重复member； - 用中文、emoji 或 UTF-8 多字节字符串做
member，误以为“字典序 = 语义序”——但 Redis 只认字节序，"苹果"（UTF-8 为\xe8\x8b\xb9\xe6\x9e\x9c）永远排在"香蕉"（\xe9\xa6\x99\xe8\x95\x89）前面，跟拼音无关。
如何验证 ZSet 的字典序是否真稳定？
直接用最小闭环测试：
ZADD testzset 100 "a2" 100 "a0" 100 "a1" ZRANGE testzset 0 -1
结果必为："a0" → "a1" → "a2"，无论插入顺序、Redis 版本、是否重启。原因就是 Redis 内部调用 memcmp() 对 member 字节逐位比较，无任何随机性。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
注意：ZRANGE 默认升序（score 小→大），若要“高分在前”，必须用 ZREVRANGE，否则会误以为“排序反了”。
真正需要干预的场景：同分时想按时间先后排序
这不是“修复混乱”，而是**业务需求超出默认规则**。ZSet 默认字典序无法表达“谁先来”，此时需主动编码时间信息到 score：
- 推荐方案：用整数拼接，如
combined_score = original_score * 1000000000000L + (Long.MAX_VALUE - timestamp)，确保时间越早，组合分越高（配合ZREVRANGE）； - 避免浮点精度陷阱：不要用
score + (1.0 - timestamp/1e13)，IEEE 754 在大数值下会丢失低 3–4 位毫秒精度； - 注意
score范围：Redisscore是 double，安全整数上限约2^53 ≈ 9e15，13 位时间戳 × 1e3 分辨率已逼近边界，建议用 10 位秒级时间戳更稳妥； - 别依赖
ZADD ... LT/GT做“首次插入保护”：它只比分数，不感知时间，无法替代组合分逻辑。
容易被忽略的关键点
member 的唯一性不是可选项，是 ZSet 正常工作的前提。一旦你发现“同分元素似乎没按字典序排”，第一反应不该是怀疑 Redis，而应检查：
- 是否真的传入了不同
member字符串？比如空格、不可见字符、大小写差异； - 是否用了
nx或xx参数导致部分ZADD实际没生效，造成数据集不完整； - 是否在 Lua 脚本里误用了
redis.call('ZADD', ...)但没处理返回值，掩盖了覆盖行为。
字典序稳定是底层保障，不是配置项。想绕过它，就得自己把业务维度（如时间）编进 score；想质疑它，先用 HEXSTR 检查 member 字节流。
