优先选HASH存字段级数据，因其支持原子单字段更新、兼容性好；若需嵌套结构且环境已启用RedisJSON模块，再考虑JSON.SET。
用 SET 存 JSON 字符串，简单但查改困难
直接把 JSON 序列化后塞进 SET 是最直觉的做法，比如 SET user:1001 '{"name":"Alice","age":30}'。它适合只读场景或整条更新——比如用户资料页每次全量刷新。
但一旦要改其中某个字段（比如只更新 age），就得先 GET 出来、反序列化、改完再 SET 回去，网络 + CPU 开销双高；更麻烦的是，Redis 本身无法校验 JSON 格式，存个语法错误的字符串（比如少个引号）也不会报错，等到应用层 JSON.parse() 才崩。
常见错误现象：ERR invalid JSON 从不出现，但你的业务代码频繁抛 SyntaxError: Unexpected token。
- 别在客户端做空值判断后再序列化——
null、undefined进 JSON 容易引发歧义 - 如果用 Node.js，
JSON.stringify(obj, null, 2)带缩进的格式会显著增大内存占用，生产环境一律用紧凑格式 - Redis 7.0+ 支持
JSON.SET，但老版本只能靠应用层兜底，别默认假设 JSON 功能可用
用 HASH 存字段级数据，天然支持原子更新
HASH 把 JSON 的每个键映射成 field，比如 HSET user:1001 name "Alice" age "30"。这时候改年龄只要 HSET user:1001 age "31"，一次命令完成，不拉数据、不序列化、不锁整条记录。
适用场景很明确：需要高频单字段读写、有部分更新需求、或者字段间更新逻辑相互独立（比如头像 URL 和登录时间互不影响）。
注意 HASH 的 value 全是字符串，存数字得自己转——HGET user:1001 age 返回的是 "30" 而不是 30，业务层要手动 parseInt 或 parseFloat；嵌套对象（如 address: { city: "Beijing" }）没法直接展开，只能扁平化成 address:city 或整个当字符串存。
- 字段名含冒号、点号等特殊字符时，
HSET没问题，但某些客户端（如旧版 Jedis）可能解析异常，建议统一用下划线 -
HLEN查字段数比STRLEN查 JSON 长度快得多，适合做轻量元数据统计 - 大量小
HASH（比如每条记录只有 2~3 个 field）比大STRING更省内存，Redis 内部对短HASH用了 ziplist 编码
RedisJSON 模块不是银弹，得看部署环境
如果你用的是 Redis 6.2+ 且启用了 redisjson 模块，那 JSON.SET、JSON.GET $..name、JSON.DEL 就能真正按路径操作 JSON。但它不是默认内置功能——Docker 镜像、云数据库（如阿里云 Redis）、K8s Helm Chart 很多都不带这个模块，得自己编译或确认服务商是否开启。
典型翻车点：本地开发用 JSON.GET user:1001 $.name 一切正常，上线后报错 ERR unknown command `JSON.GET`。
- 检查是否启用：
MODULE LIST输出里要有name:rejson或name:json -
JSON.SET默认不覆盖，加NX或XX控制行为，漏写会导致静默失败 - 路径表达式支持有限，
$[?(@.age > 30)]这种过滤语法在 7.0+ 才稳定，低版本别依赖
选型关键其实就两条：更新粒度 + 环境可控性
如果业务要求“每次只改一个字段”“并发写不同字段不能互相阻塞”，HASH 是最稳的选择，兼容性好、性能透明、调试直观；如果必须保留嵌套结构、又确定线上环境已装 RedisJSON，那路径操作确实省事。
最容易被忽略的一点：JSON 字段的编码方式会影响内存碎片。比如用 SET 存一个 5KB 的 JSON，Redis 分配一块连续内存；而同样内容拆成 20 个 HASH field，可能分散在多个小内存块里——长期高频增删后，INFO memory 里的 mem_fragmentation_ratio 会悄悄升高，GC 压力变大。
