redis hash根据数据规模自动选择listpack（或旧版ziplist）或hashtable编码：字段数≤512且所有值长度≤64字节时用listpack，节省内存；任一条件不满足则不可逆地升级为hashtable，保障o(1)读写性能。
Hash 为什么有时用 ziplist，有时用 hashtable？
Redis Hash 不是固定用某一种结构存的，它会根据数据规模和字段长度自动切换编码方式。关键看两个配置项：hash-max-listpack-entries 和 hash-max-listpack-value（Redis 7.0+ 已将 ziplist 替换为更安全的 listpack，但行为逻辑一致）。
满足以下两个条件时，用 listpack 编码：
- 字段总数 ≤
hash-max-listpack-entries（默认 512） - 每个字段值长度 ≤
hash-max-listpack-value（默认 64 字节）
只要任一条件不满足，就会立即升级为 hashtable 编码。这个过程不可逆——一旦转成 hashtable，哪怕后续删到只剩一个字段，也不会降级回 listpack。
listpack 存储格式：线性排列，field-value 交错
listpack 是一块连续内存，把所有字段按 [field1, value1, field2, value2, ..., fieldN, valueN] 的顺序紧挨着存。没有指针、没有哈希桶、没有链表开销。
查找某个 field 时，Redis 从头开始扫描，每次跳过两个元素（一个 field + 一个 value），直到匹配上。所以时间复杂度是 O(N)，但 N 很小（≤512），且局部性好，CPU cache 友好。
常见坑点：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 字段名或值里含二进制数据（比如 \x00）会导致
listpack解析失败，强制转成hashtable - 哪怕只有一对 field-value，只要值长度 >64 字节，就直接用
hashtable，不是“先试 listpack 再升级”
hashtable 编码：真正的字典结构，带渐进式 rehash
底层复用 Redis 全局字典（dict）实现，包含两个哈希表：ht[0]（主表）和 ht[1]（迁移中表）。rehash 不是一次性搬完，而是穿插在每次命令操作中逐步迁移 bucket。
容易忽略的细节：
-
rehash过程中，读写都同时查ht[0]和ht[1]，所以单次操作可能变慢，但不会卡住整个实例 - 如果 Hash 正在 rehash，执行
HLEN返回的是两个表的总used之和，不是实时精确值（但业务通常不需要这种精度） -
hashtable的每个 entry 存的是指针，真正数据（field/value 字符串）在别处分配，所以内存碎片更明显
怎么确认当前 Hash 用的是哪种编码？
用 OBJECT ENCODING key 命令就能直接看到：
127.0.0.1:6379> HSET user name "Alice" age "30" (integer) 2 127.0.0.1:6379> OBJECT ENCODING user "listpack" 127.0.0.1:6379> HSET user bio "A very long bio..." # 超过 64 字节 (integer) 1 127.0.0.1:6379> OBJECT ENCODING user "hashtable"
注意：listpack 和 hashtable 的内存布局差异极大，不能靠 MEMORY USAGE 的绝对值反推编码类型——小数据用 listpack 省空间，但大字段反而可能因冗余编码略费内存。
真正影响性能的不是“用了哪种结构”，而是“什么时候切换”以及“切换后有没有触发 rehash”。高频写入场景下，突然从 listpack 升级到 hashtable，紧接着又触发扩容，可能造成短时延迟毛刺——这点在压测时容易被忽略。
