redis hash 类型适合存储扁平化对象属性，而非真正嵌套的复杂对象；其核心优势在于字段级原子操作（如 hincrby、hmget），适用于频繁局部读写场景，但字段过多或值过大时性能下降。
Redis 的 Hash 类型不适合直接存储真正意义上的“复杂对象”——比如嵌套对象、数组、日期实例、函数或二进制数据。它只接受字符串作为 value，所有字段名（field）也必须是二进制安全的字符串，但实际使用中极易因编码/客户端限制出错。
真正能存的，是已预处理成扁平化字符串结构的对象属性集合。是否适合用 Hash，取决于你后续怎么读、怎么改、以及对象本身怎么“切”。
什么时候该用 Hash 存对象？看访问模式
不是“对象能不能放”，而是“你是不是经常只读/写其中几个字段”：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 需要频繁查
username和avatar_url，但几乎不碰last_login_ip或preferences→ 用HMGET user:123 username avatar_url比GET user:123再 JSON.parse() 更省带宽和 CPU - 要对
login_count做原子自增 →HINCRBY user:123 login_count 1可靠；而 JSON 存在 String 里，就得 GET-修改-SET，有并发风险 - 字段总数长期稳定在几十个以内，且单个 value 长度普遍 Hash 底层更紧凑
- 字段名固定、无动态生成（如
tags.0.name）、不含空格或控制字符 → 避免某些客户端（如redis-py）静默截断或报错
哪些“复杂对象”必须先扁平化或序列化？
所有非字符串类型都得转成字符串，否则会丢数据或隐式转换不可控：
-
Date对象 → 必须转成 ISO 字符串（date.toISOString()）或时间戳（date.getTime()），不能依赖toString() - 布尔值 → 显式转
'1'/'0'，别传true让 Redis 自动转成"true"（取出来是字符串，不是布尔） -
null→ 用空字符串''或占位符如'NULL'，避免字段缺失导致逻辑误判 - 数组（如
roles: ['admin', 'editor']）→ 必须 JSON.stringify() 成'["admin","editor"]'，取出来后手动JSON.parse() - 嵌套对象（如
address: { city: 'Beijing', zip: '100000' }）→ 不能直接存address.city为 field 名（它只是个字符串，不是嵌套路径），得展平成address_city、address_zip，或整个address字段存 JSON 字符串
为什么不用 String + JSON？关键在更新粒度
如果对象字段极多（>500）、或每次操作都是全量读写（比如用户资料页每次加载全部信息），HGETALL 会变慢，网络传输开销大，此时 SET user:123 '{"name":"A","age":30,...}' 更简单稳定。
-
HGETALL返回所有field/value对，字段越多，响应体越大，还可能触发 Redis 的慢日志阈值（默认 10ms） - 某些客户端对超大
Hash的解析有额外开销（比如 Java 的 Jedis 会把整个Map加载到内存再遍历） - 如果字段名含非 UTF-8 字节（比如某些旧系统导出的二进制 ID），
redis-py会报UnicodeDecodeError，而String方案不受影响
最常被忽略的一点：字段名本身不是“结构”，只是字符串。HSET user:1001 address.city "Beijing" 看似嵌套，实际只是存了一个叫 address.city 的字段，跟 foo_bar 没本质区别。真正的嵌套逻辑，必须由业务代码自己维护——Redis 不管，也不懂。
