Redis中String无法嵌套Hash，因数据类型严格隔离；应直接用Hash存主体（如HSET user:1001 name "Alice"），String仅存序列化或只读数据。
Redis里String嵌套Hash为什么行不通
Redis的String值只能存纯字符串，不能直接“包含”一个Hash结构。你用SET user:1001 "{\"name\":\"Alice\",\"age\":28}"存的是JSON文本，不是真正的Hash——后续没法用HGET、HINCRBY等命令操作字段，只能整条取出来解析，失去Redis原生Hash的原子性和效率。
常见错误现象：HGET user:1001 name返回(nil)，但GET user:1001能拿到JSON；或者业务里频繁GET + JSON.parse + 修改 + SET，并发时丢数据。
- 根本原因：Redis数据类型是严格隔离的，
String和Hash是两类key，不能混用 - 真正想表达“用户+属性”的关系，应该用
Hash本身做主结构，而不是把Hash塞进String - 如果必须保留
user:1001这个key名且需要字段级操作，就别用SET，改用HSET user:1001 name "Alice" age 28
用Hash存主体+String存关联元数据的典型场景
比如订单系统中，“订单主体信息”适合用Hash（字段可增删、支持HGETALL批量读），而“订单快照序列化结果”或“临时签名token”这类只读、不拆解的值，更适合单独用String key存。
示例结构：
HSET order:20240520001 status "paid" amount "99.9" uid 12345
SET order:20240520001:snapshot '{"status":"paid","items":[{"id":1,"qty":2}]}'
-
order:20240520001用Hash支撑实时查询、状态更新（HSET order:20240520001 status "shipped"） -
order:20240520001:snapshot用String避免重复序列化，也方便设置独立过期时间（EXPIRE order:20240520001:snapshot 3600） - 两者key命名用相同前缀，便于运维识别归属，也支持
KEYS order:20240520001*（生产慎用）或SCAN批量清理
Hash字段值里存JSON字符串的坑与权衡
有时候确实需要在Hash某个字段里放结构化内容，比如ext_info字段存用户扩展配置。这时可以存JSON字符串，但必须清楚代价：
- Redis不解析JSON内容，
HGET order:20240520001 ext_info返回的是完整字符串，业务层要自己json.loads()或JSON.parse() - 无法对JSON内部字段做原子操作（比如给
ext_info.version自增），也不能用HEXISTS判断ext_info里是否有某个子键 - 如果该字段更新频繁且JSON较大，每次
HSET都是全量覆盖，网络和内存开销比拆成多个Hash字段高 - 替代方案：把JSON扁平化，例如
ext_version、ext_lang作为独立Hash字段，用原生命令操作
Lua脚本协调String与Hash的原子操作
当业务逻辑强制要求“先读Hash字段A，再根据结果写String key B”，又不能容忍中间状态不一致时，得用EVAL保证原子性。比如发放优惠券：查用户剩余次数（Hash里的coupon_left），够才生成token（String），并扣减次数。
示例脚本（注意key参数传入）：
EVAL "local left = redis.call('HGET', KEYS[1], 'coupon_left'); if tonumber(left) > 0 then redis.call('HINCRBY', KEYS[1], 'coupon_left', -1); redis.call('SET', KEYS[2], ARGV[1], 'EX', ARGV[2]); return 1 else return 0 end" 2 user:789 coupon:789:token123 "abc123" 3600
- 脚本里
KEYS[1]是Hash key，KEYS[2]是String key，避免硬编码，方便复用 - 必须用
tonumber()转数字，否则字符串比较会出错（如"10" - 生产环境注意Lua脚本长度限制（默认
lua-time-limit毫秒），复杂逻辑建议拆到客户端，靠事务+重试兜底
多结构协作的真实难点不在语法，而在业务语义边界是否清晰——哪个字段必须原子更新，哪个可以接受短暂不一致，这个判断比怎么写命令更重要。
