128个元素+64字节是实测权衡结果：兼顾连续内存布局、cache行命中与微秒级查找，超阈值则内存重分配和遍历开销陡增，listpack（非ziplist）在此约束下实现高效紧凑存储。
ziplist 编码触发条件为什么是 128 个元素 + 64 字节？
这不是拍脑袋定的 magic number，而是实测权衡的结果：在绝大多数小规模缓存场景（如用户最近 50 条操作记录、商品价格排行榜前 100 名），zset-max-ziplist-entries=128 和 zset-max-ziplist-value=64 能让 listpack（Redis 7.0+ 替代 ziplist 的新结构）保持单块连续内存，同时线性查找耗时仍在微秒级可接受范围。
超过这个阈值后，两个问题会快速凸显：
- 插入/删除引发的内存重分配概率上升，尤其当频繁
ZADD或ZREM时，memcpy开销明显 - 哪怕只有 200 个元素，线性遍历平均也要比对 100 次 —— 而跳表此时平均只需比对 8 次（log₂200 ≈ 7.6）
ziplist 查找慢但 Redis 还坚持用？关键在缓存行命中
ziplist 的 O(N) 查找确实不优雅，但它胜在所有数据挤在一段连续内存里。现代 CPU 访问紧邻地址时，预取器（prefetcher）能提前把后续几个节点载入 L1 cache —— 实际测试中，128 个元素的 listpack 常驻于同一 cache line 或相邻几行，遍历延迟极低。
而跳表每个节点是独立 malloc 出来的，指针跳转极易引发 cache miss。小数据量下，这种空间局部性优势直接盖过了算法复杂度劣势。
你可以用 DEBUG OBJECT key 验证：插入 127 个短字符串后查编码是 listpack；第 128 个只要超 64 字节（比如塞入一个长 UUID），立刻触发转为 skiplist。
内存节省到底省了多少？看实际字节数差异
以存储 100 个 "user:1001"（10 字节）+ 分数（8 字节 double）为例：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- listpack：约 100 × (10 + 8 + 3 字节元数据) ≈ 2100 字节（紧凑打包，无指针）
- skiplist + dict：跳表节点本身约 100 × 48 字节 = 4800 字节，加上字典哈希桶、指针等，总开销常超 8000 字节
内存占用翻倍以上。这对内存敏感的容器化部署（如 Redis 在 512MB 容器里跑几十个实例）是硬约束。
注意：ZRANGE key 0 -1 WITHSCORES 这种全量读，在 listpack 下是顺序 memcpy，快得离谱；换成 skiplist 就要跨多个内存页随机访问节点 —— 小数据量时，这差距比算法理论值更刺眼。
别只盯着 ziplist，listpack 才是当前默认
Redis 7.0 起已用 listpack 全面替代 ziplist，虽然配置项名还叫 zset-max-ziplist-*，但底层逻辑已不同：listpack 支持更灵活的长度编码、无嵌套结构、更安全的边界检查。
这意味着你改配置时，实际生效的是 listpack 的阈值；而旧版 ziplist 的“连锁更新”缺陷（修改中间元素可能引发整段重写）在 listpack 中已消除。
真正容易被忽略的是：这两个阈值是「与」关系，必须同时满足。比如你有 120 个元素，但其中一个是 65 字节的 JSON 字符串，ZADD 会立刻升级为 skiplist + dict，且不可逆回退 —— 即使你之后删掉那个长元素，结构也不会自动降级。
