redis hash不支持嵌套对象，必须扁平化为一级键值对（如profile:name）、存json字符串（需客户端解析），或拆分为独立key引用（如addr:201），三者在原子性、一致性、性能上各有权衡。
Hash 里不能直接存嵌套对象，得扁平化
Redis 的 HASH 类型只支持字符串类型的字段值，不接受 JSON、嵌套 HASH 或其他 Redis 数据类型作为字段值。你试图用 HSET user:1001 profile '{"name":"Alice","addr":{"city":"Beijing"}}' 存进去，实际只是把整个 JSON 当成一个字符串塞进去了——后续没法用 Redis 命令直接查 profile.addr.city。
- 所有嵌套结构必须提前展开成一级键值对，比如：
HSET user:1001 profile:name Alice profile:addr:city Beijing profile:addr:zip 100000 - 字段名用冒号分隔是常见约定，但不是强制；只要语义清晰、避免冲突即可（比如别用
user:1001:name，那属于 KEY 层级命名） - 如果原始结构深度大、字段多，手动扁平化易错，建议在业务代码里统一做序列化前的转换，而不是靠人工拼 key
用 JSON 字符串存进 Hash 字段也行，但得自己解析
如果你坚持保留嵌套结构的可读性，可以把整个对象 JSON 序列化后存为单个字段，比如 HSET user:1001 profile '{"name":"Alice","addr":{"city":"Beijing"}}'。这能存，也能取，但 Redis 本身完全不理解里面的内容。
-
HGET user:1001 profile返回的是完整 JSON 字符串，后续解析、修改、更新都得靠客户端完成 - 想改其中某个子字段（比如只更新 city），必须先
HGET出来、JSON.parse、改完、JSON.stringify、再HSET回去——有并发风险，且无法原子操作 - 这种做法适合「只读」或「整对象替换」场景，比如用户配置快照；不适合高频局部更新
Hash + 多 Key 组合比纯 Hash 嵌套更灵活
真要支持部分更新、原子操作、以及跨对象关联（比如多个用户共用一个地址 ID），不如把嵌套结构拆成独立 Redis Key，再用 Hash 字段存引用。
- 例如：
SET addr:201 '{"city":"Beijing","zip":"100000"}'，然后HSET user:1001 profile:name Alice profile:addr_id 201 - 这样更新地址时只需改
addr:201，所有引用它的用户自动生效；HSET和SET都是原子的 - 代价是读取时多一次网络往返（
HGET+GET），但换来的是数据一致性、复用性和可维护性 - 注意：Redis 没有外键约束，
addr:201被删了而user:1001还指着它，就是脏引用——得靠业务层兜底或加 TTL 对齐
别忽略内存和序列化开销
扁平化后字段数变多，JSON 字符串存整对象会重复存储字段名，这两种方式在内存占用和网络传输上差异明显。
- 100 个用户，每人 profile 有 8 个字段，扁平化后就是 800 个
HASH字段；而 JSON 方式只有 100 个字段，但每个值多带约 30% 的冗余字符（引号、冒号、逗号、花括号） -
HLEN查字段数、HGETALL批量取值，在字段极多时可能阻塞主线程（尤其 Redis HSCAN 分批 - 如果字段值普遍很小（如全是短字符串），扁平化通常更省内存；如果嵌套深、字段名长、值大，JSON 可能反而紧凑些——得实测
MEMORY USAGE
嵌套结构怎么存，本质是在「Redis 原生能力边界」和「业务操作便利性」之间找平衡点。没有银弹，但最容易被忽略的是：一开始图省事用 JSON 字符串硬塞，等要加字段校验、做局部更新、对接缓存穿透防护时，才发现改不动了。
