ZSet需同时支持O(1)单点查询和O(logN)范围操作，故不能只用Listpack（O(N)查改）或跳表（O(logN)查分值）；其编码切换由元素数≤128且成员长度≤64字节双条件触发，不满足则升为skiplist+dict，且不可降级。
跳表和Listpack为什么不能只用一种？
因为ZSet要同时扛住两种完全不同的访问模式：高频的单点查询（比如查某个用户的当前积分 ZSCORE）和高频的范围操作（比如取排行榜前100名 ZRANGE）。跳表能高效做范围，但单点查分值得 O(log N)；Listpack（Redis 7.0+ 替代了旧版 ziplist）内存紧凑、小数据时遍历快，但插入/删除/查分值全是 O(N)。只选一种，必然在某类场景下性能崩掉。
编码切换的实际触发条件是什么？
Redis 不是按“时间”或“使用频率”切，而是看两个硬指标是否同时满足：
- 元素总数 ≤
zset-max-ziplist-entries（默认128） - 每个 member 字符串长度 ≤
zset-max-ziplist-value（默认64）
只要任一条件不满足，立刻从 Listpack 升级为 skiplist + dict 复合结构。注意：升级是单向的，降级不会发生——哪怕你后续删到只剩1个元素，它也还是 skiplist。
为什么升级后不降级？
降级成本太高，且收益极低。从 skiplist 回退到 Listpack 需要重建整个结构、重新排序、逐个拷贝数据，这会阻塞主线程，引发延迟毛刺。而实际业务中，ZSet 一旦规模上去（比如热门话题榜突破128条），几乎不会长期缩回到极小状态。与其花大代价做低概率优化，不如稳住高水位表现。这也是 Redis “简单可靠优于过度智能”的典型体现。
你在监控里最容易忽略的关键点
别只盯着 TYPE 和 OBJECT ENCODING 看类型，真正影响性能的是底层结构切换的临界点是否被你无意中踩中。比如批量导入130个用户ID，每个ID是UUID（36字节），看似没超 64，但总数破了 128，整张榜瞬间从 Listpack 切成 skiplist —— 内存占用翻倍、首次插入延迟跳升。这种抖动在压测或上线时最难复现，却最伤体验。
