redis原生string类型无法解析json字段，必须用redisjson模块实现路径查询、原子更新等能力；启用需加载模块，使用json.set/json.get命令，性能提升体现在频繁子字段操作场景。
Redis 原生 String 类型不能直接解析或操作 JSON 字段，硬存 JSON 字符串只是“字符串”，查字段、改字段、校验结构都得靠应用层反序列化——性能差、易出错、不安全。真正支持 JSON 操作的是 RedisJSON 模块，它让 Redis 具备原生 JSON 解析、路径查询、原子更新能力。下面说清楚怎么用、为什么换、以及踩过哪些坑。
为什么不能只用 SET/GET 存 JSON 字符串
很多人图省事，把 json.dumps(obj) 结果塞进 SET user:1001 "{...}"，以为“能存能取就行”。问题在后续操作：
- 想改
user:1001里address.city字段？得GET→json.loads()→ 修改 dict →json.dumps()→SET：四次内存拷贝 + 全量写入，高并发下 CPU 和带宽都吃紧 - 想查所有
status == "active"的用户？必须遍历所有 key + 全量解析，没法用索引，O(n) 扫描 - 多个客户端同时更新同一 JSON 对象的两个不同字段（比如
email和phone），没有原子性保障，可能丢更新 - JSON 格式错误（如多逗号、单引号）只在应用层报错，Redis 不校验，脏数据悄无声息入库
启用 RedisJSON 模块的实操要点
不是所有 Redis 实例都默认加载 RedisJSON，必须确认模块已载入且版本兼容（建议 ≥ v2.4）：
- 连上 Redis 后执行
MODULE LIST，看输出里有没有name:rejson或name:RedisJSON - 若没加载，在 redis.conf 加
loadmodule /path/to/rejson.so，或启动时加--loadmodule /path/to/rejson.so - Docker 用户推荐用官方镜像：
docker run -d --name redis-json -p 6379:6379 redis/json（自动集成） - 注意：Redis Stack（redis.io/download#redis-stack）已内置
RedisJSON+RediSearch+RedisGraph，开箱即用
用 JSON.SET / JSON.GET 替代 SET / GET 的关键差异
JSON.SET 和 JSON.GET 是核心命令，但参数语义和行为与原生命令不同：
-
JSON.SET user:1001 $ '{"name":"Alice","address":{"city":"Beijing"}}'：第二个参数是 JSONPath 表达式，$表示根节点；必须传合法 JSON 字符串，非法格式会直接报错ERR invalid JSON -
JSON.GET user:1001 $.name只返回"Alice"，不是整个对象；支持多路径：JSON.GET user:1001 $.name $.address.city - 更新子字段用
JSON.SET user:1001 $.address.city '"Shanghai"'（注意值是带双引号的 JSON 字符串！），不是"Shanghai" - 删字段用
JSON.DEL user:1001 $.address；判断是否存在用JSON.TYPE user:1001 $.address（返回object/string/nil）
性能提升的真实边界在哪
别盲目替换——RedisJSON 的优势集中在「频繁读写 JSON 内部字段」场景。如果只是存整条配置、偶尔全量读取，String + 应用层解析反而更轻量：
- 单 key 单字段更新：比 String 方案快 3–5×（避免反序列化 + 全量写入）
- 大 JSON（>10KB）随机读小字段：
JSON.GET key $.a.b.c比GET key+ Pythonjson.loads()快 2×+，因模块内 C 层直接跳转解析 - 但首次
JSON.SET开销比SET高 20%–30%，因为要语法校验 + 构建内部 AST 树 - 内存占用略高（约 +15%），因需维护 JSON 结构元信息；若存海量极简键值对（如
{"id":1,"v":2}），String 更省
真正容易被忽略的是：JSONPath 支持有限（不支持过滤器如 $[?(@.age > 18)]，除非用 JSON.GET ... INDICES 配合 RediSearch），复杂查询仍得靠应用层兜底。
