Redis 7.0默认启用listpack，但易因配置或操作退化为quicklist或hashtable：需满足hash-max-listpack-entries≤128、hash-max-listpack-value≤64，且避免高频HDEL/HSET混合导致realloc碎片；DEBUG OBJECT key可验证真实encoding。
Redis 7.0 中 listpack 已默认启用，无需手动“切换”，但必须避免配置或操作导致它被绕过——否则实际用的还是 quicklist 或 hashtable，完全不省空间。
为什么你的 Hash 没走 listpack？检查这几个配置项
Redis 7.0 虽然用 hash-max-listpack-entries 和 hash-max-listpack-value 替代了旧参数，但只要其中一个不满足，就会立刻升级为 hashtable：
-
hash-max-listpack-entries默认是 128，表示字段数 ≤ 128 才可能用 listpack；超过就强制转hashtable -
hash-max-listpack-value默认是 64，指每个 value 的字节长度不能超 64；比如存一个"{\"id\":1,\"name\":\"a\"}"（JSON 字符串），实际长度 28 字节，没问题；但若 value 是 base64 图片片段，很容易突破 - 如果把
hash-max-listpack-entries设成负数（如 -1），Redis 会直接禁用 listpack，降级为quicklist（底层是双向链表 + 多个 listpack 节点），失去紧凑优势
验证 key 是否真在用 listpack
别猜，用 DEBUG OBJECT key 看真实 encoding：
- 返回
encoding: listpack→ 成功，数据正享受紧凑布局和低碎片率 - 返回
encoding: hashtable→ 已越界，要么字段太多，要么某个 value 超长 - 返回
encoding: quicklist→ 配置被绕过，或 Redis 版本/编译选项异常（极少见）
注意：OBJECT ENCODING key 也能看，但 DEBUG OBJECT 还能附带内存地址、refcount 等信息，更适合排查退化原因。
高频 HDEL/HSET 混合操作会让 listpack 实际失效
listpack 是一块连续内存，不支持原地删除中间字段——HDEL 某个 field 时，Redis 必须 realloc 整块内存并复制剩余 entry。频繁删改会快速产生内存碎片，jemalloc 很快就无法复用桶，导致 mem_fragmentation_ratio 上升，抵消 listpack 本应带来的收益：
- 实测：每秒 500 次 HDEL + HSET 交替，在 10 分钟内，原本
mem_fragmentation_ratio ≈ 1.15的 listpack hash 可能升到 1.4+，逼近 ziplist 水平 - 对策不是禁用 listpack，而是评估业务是否真需要随机删字段；若只是追加或覆盖，
HSET完全安全；若必须删，考虑改用HSCAN+HMSET重建，减少 realloc 次数
listpack 不是万能解药：它只管“小而密”，不管“大而活”
listpack 的价值集中在中小规模、低变更频率的场景。一旦 Hash 字段数稳定在 100 左右、value 都是短字符串（如 user:1001 → {“status”:“active”, “role”:“user”, “lang”:“zh”}），它就能把内存占用压到 hashtable 的 60% 左右；但如果你的 Hash 是动态聚合结果（比如实时统计维度），字段数波动大、value 含序列化对象，那 listpack 反而会因反复升级/降级带来额外开销。
真正容易被忽略的是：listpack 降低的是“假性淘汰”，不是“真实内存压力”。即使碎片率从 1.6 降到 1.2，只要 maxmemory 设置偏紧，或者业务持续写入，淘汰该触发还是触发——它只是让你多撑一会儿，而不是不用淘汰。
