Redis Lua脚本中无法直接使用嵌套table模拟字典，必须通过冒号分隔的扁平key（如"user:1001:profile:city"）配合HSET/GET操作，或用cjson.encode/decode序列化为JSON字符串存储，但后者不支持原子性更新子字段。
Redis Lua脚本里不能直接用嵌套 table 当字典
Redis 的 Lua 环境（redis.call() 所在上下文）不支持原生嵌套 table 结构——你写 local d = {a = {b = 1}}，这个 d.a 在传给 Redis 命令时会丢失层级，因为 Redis 协议只认扁平化的 key-value 或数组。所有“嵌套字典”都得靠 key 命名约定或序列化来模拟。
常见错误是试图用 redis.call('HSET', 'user:1001', 'profile', cjson.encode({age=25, city='bj'})) 存整个结构，结果后续没法原子性更新 profile.city ——HSET 只能设 field，不能穿透 JSON 字段。
- 真正可行的路径只有两条：用冒号分隔的扁平 key（如
"user:1001:profile:city"），再配合redis.call('SET')或HSET； - 或者把嵌套结构整体存成 JSON 字符串，但必须用
cjson.decode()/cjson.encode()在 Lua 里手动拆解合并，且无法原子更新子字段。 - 别依赖
redis.sha1hex或自定义序列化函数替代cjson——Redis 内置只带cjson，其他库不存在。
用 HSET + 冒号命名模拟嵌套字典最实用
比如想表达用户配置里的多层结构：{theme: {color: "dark", font: "sans"}, notify: {email: true, push: false}}，就展开成 flat key：
redis.call('HSET', 'user:1001', 'theme:color', 'dark', 'theme:font', 'sans', 'notify:email', '1', 'notify:push', '0')
这样既能用 HGETALL 一次性读出所有字段，也能用 HGET user:1001 "theme:color" 单独取值，还能用 HEXISTS 判断 theme:font 是否存在。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写入时注意：一次
HSET最多支持 1024 个 field-value 对，超了得拆成多次调用； - 读取时
HGETALL返回的是扁平列表，Lua 里得自己按:分割重组，例如local k,v = unpack({key,val})后用string.split(k, ':')（但 Redis Lua 没内置split，得手写）； - 删除某一层（如整个
theme）只能用HEVAL配合SCAN模糊匹配 key 前缀，再逐个HDEL——Redis 本身不支持HDEL user:1001 "theme:*"这种通配。
cjson.encode/decode 能存嵌套结构，但失去原子性更新能力
如果真需要保持 Lua 里的嵌套 table 形态，只能走 JSON 路线：
local data = cjson.decode(redis.call('GET', 'user:1001:config') or '{}')
data.theme = data.theme or {}
data.theme.color = 'dark'
redis.call('SET', 'user:1001:config', cjson.encode(data))
这段代码能工作，但代价明显：
- 每次修改都要先
GET整个 JSON、解码、改局部、再编码、SET回去——不是原子操作，高并发下可能覆盖他人写入； - JSON 字符串大小受 Redis 单 value 512MB 限制，但更现实的瓶颈是序列化/反序列化开销，尤其大结构；
-
cjson不支持undefined、NaN、循环引用，遇到会报错ERR Error running script (call to f_...): user_script:xx: bad argument #1 to 'encode' (table contains invalid value)； - 别用
redis.call('JSON.SET')——那是 RedisJSON 模块的命令，标准 Redis 不带，Lua 脚本里调用会报ERR unknown command `JSON.SET`。
实际选型关键看更新粒度和一致性要求
如果业务要求“改一个配置项必须不被并发覆盖”，就别碰 JSON 方案，老实用扁平 HSET + 明确 key 路径；如果只是初始化一批嵌套数据、后续基本只读，JSON 存一次也够用。
最容易被忽略的是 key 命名边界问题：用 user:1001:profile:city 没问题，但若字段名本身含冒号（比如城市名是 San:Francisco），就会破坏层级解析逻辑——得提前约定转义规则，比如把冒号替换成 \:，并在 Lua 里统一处理。
