Hash在小字段场景（≤512字段且单field/value≤64字节）用listpack/ziplist编码省内存，超阈值转hashtable致内存突增；相比String存JSON，Hash支持字段级原子操作、降低网络与CPU开销，但不支持嵌套结构和字段级过期。
看内存占用：Hash在小字段场景下明显更省，但超阈值会突增
Redis 对 Hash 的底层编码不是固定的：字段数 ≤ 512 且每个 field 和 value 长度都 ≤ 64 字节时，用 ziplist；否则自动升级为 hashtable。这个切换点非常关键——ziplist 是连续内存块，只占 1 个 redisObject 头（16B）+ 少量压缩开销；而 hashtable 虽仍比多个独立 String 省，但指针、桶数组、链表节点等额外结构会让内存翻倍甚至更高。
反观 String 存 JSON：user:1001 这个 key 就要承担完整的 redisObject（16B） + SDS 头（8B） + JSON 字符串本体。如果同一用户还存了 user:1001:profile、user:1001:settings 等多个 String，元数据开销直接线性叠加。
实操建议：
- 用
DEBUG OBJECT user:1001查看实际编码类型和 serializedlength（注意：生产环境慎用，可能阻塞） - 用
MEMORY USAGE user:1001对比 Hash 和 JSON String 的真实内存占用（推荐） - 字段平均长度 > 64 字节 或字段数 > 512 时，别硬凑
ziplist，提前按业务拆分 key（比如user:1001:base+user:1001:ext）
测字段级读写：Hash 的 HGET/HSET 比 JSON String 的 GET+反序列化+SET 快 3–5 倍
一次 HGET user:1001 phone 是纯内存寻址，O(1)，不碰其他字段；而 JSON String 要走完整链路：GET user:1001 → 客户端反序列化 → 修改 phone → 序列化 → SET user:1001。光网络往返就多一次，CPU 和 GC 压力也集中在客户端。
并发更新时差异更致命：两个请求同时改 JSON String，必然出现覆盖；而 HSET user:1001 name "A" 和 HSET user:1001 city "B" 完全互不干扰，Redis 内部保证原子性。
常见错误现象：
- 接口 P99 延迟毛刺集中在用户资料更新接口，尤其 JSON > 2KB 时
- 日志里频繁出现 “unexpected field value” —— 实际是并发写导致的字段错乱
实操建议：
- 压测时对比
HGET user:1001 name与GET user:1001+ JSON 解析耗时，差距通常在 0.1ms vs 0.4–0.6ms - 避免在 Lua 脚本里对 JSON String 做 patch 操作——性能差且易出错，不如直接切 Hash
查嵌套与动态字段：JSON String 支持任意结构，Hash 只能扁平化
Hash 的 field 必须是字符串，value 也只能是字符串，不支持嵌套对象或数组。比如 {"address": {"city": "北京", "district": "朝阳"}} 这种结构，Hash 只能拆成 address:city 和 address:district 两个 field，或者整个 address 当作一个 JSON 字符串塞进去——后者又回到了 String 的老问题。
而 String 存 JSON 天然支持任意嵌套层级、动态 key 名、数组列表，前端或下游服务取整条数据时也最方便。
实操建议：
- 字段结构稳定、无嵌套、字段名可枚举（如 user 表字段）→ 优先
Hash - 需要保存日志、事件 payload、前端表单快照等动态结构 → 别强求
Hash，用String或直接上RedisJSON模块 - 真要混合使用，可约定前缀区分：比如
HSET user:1001 meta:{"ts":173...}，把 JSON 字符串当 value 存进 Hash 字段里（但失去字段级操作能力）
留意过期与淘汰：Hash 不支持字段级 TTL，整体过期只能靠 String
Redis 所有原生命令都不支持给 Hash 的某个 field 单独设过期时间。你只能对整个 key 调用 EXPIRE user:1001 3600。这意味着：如果 user:1001 里混存了长期有效的 name 和短期有效的 token，两者会被一锅端。
而 String 天然支持 per-key TTL，SET user:1001:token "abc" EX 300 就能精准控制。
实操建议：
- 字段生命周期差异大（比如用户基础信息永不过期，登录态 token 5 分钟过期）→ 拆成多个 String key，别塞同一个 Hash
- 所有字段共用一套过期策略（如缓存配置项统一 10 分钟刷新）→ Hash 更干净
- 不要试图用
HEXISTS+ 客户端时间戳模拟字段 TTL，逻辑复杂且无法触发 Redis 自动淘汰
真正卡住人的往往不是“该用哪个”，而是“字段边界怎么划”——比如用户头像 URL 和头像宽高是否该同属一个 Hash？宽高变频远低于 URL，放一起反而增加无谓的内存放大风险。这种细节没标准答案，得结合字段更新频率、长度分布、过期一致性三者现场测算。
