客户端收到的是resp多批量回复，各语言驱动将其映射为对应列表类型（如python list、java list），但解析策略不同导致嵌套结构扁平化或保留；最稳妥方案是lua中用cjson.encode返回json字符串，客户端统一json解析。
Redis Lua脚本返回数组时，客户端收到的是什么类型
Redis 服务端不“返回数组”，它返回的是 RESP 协议中的 多批量回复（multi-bulk reply）；客户端驱动根据语言特性，把这个结构映射成你熟悉的类型——比如 Python 的 list、Go 的 []interface{}、Java 的 List<object></object>。关键点在于：这个映射不是自动递归解析 JSON 或嵌套结构，只是按 RESP 层级做扁平展开。
常见错误现象：eval "return {1, {2, 3}, 'hello'}" 0 在 Python 客户端里得到 [1, [2, 3], 'hello']，但如果你用 redis-cli 执行，看到的是三行输出（1) "1"、2) "2"、3) "3"、4) "hello"），因为 redis-cli 把嵌套表展开了——这不是 bug，是 RESP 解析器实现差异。
- Python redis-py 默认把 Lua 返回的 table 映射为
list，嵌套 table → 嵌套list - Node.js ioredis 将其转为
Array，但若含nil，可能变成undefined或被过滤 - Java Jedis 返回
List<object></object>，需手动instanceof判断子项是否为List -
redis-cli不保留嵌套层级，所有子元素压平输出（除非你用--raw模式看原始 RESP）
为什么 Lua 里 return {a, {b, c}} 在某些客户端里变成一维数组
根本原因不是 Lua 脚本写错了，而是客户端对 RESP multi-bulk 的解析策略不同。RESP 规范中，一个嵌套 table 被编码为多个 *N 块（每个块描述一个子元素），而部分轻量级客户端或旧版驱动会把整个响应当作单层序列处理，跳过嵌套标记。
使用场景：你用 Lua 做批量查询后组装结果，例如 return {redis.call('GET', KEYS[1]), redis.call('LRANGE', KEYS[2], 0, -1)}，期望返回 ["val", ["a","b"]]，但 Java 应用里只拿到 ["val", "a", "b"]。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查客户端是否启用了“strict mode”或“RESP3 mode”（如 redis-py 4.0+ 默认启用 RESP3，能更好保留嵌套）
- 避免依赖默认行为：显式用
JSON.encode()把结果包成字符串再 return，由客户端json.loads()解析（适合复杂结构） - 不要在 Lua 中拼接字符串模拟嵌套（如
"["..a..","..b.."]"），这绕过 RESP 结构，失去类型语义 - 确认 Redis 版本 ≥ 6.0 且客户端支持 RESP3 —— RESP2 对嵌套 table 支持弱，容易降级为扁平化
如何让 Lua 脚本返回的嵌套结构在各客户端一致可读
最稳的方式不是靠客户端适配，而是统一输出格式：把嵌套逻辑收口到 Lua 层，返回标准 JSON 字符串。这样无论 Python/Go/JS 怎么解析 RESP，最终都走同一套 JSON 解码路径，规避驱动差异。
性能影响很小（一次 cjson.encode() 开销远低于网络往返），且完全可控。
- Redis 需加载
cjson模块（多数发行版已内置，无需额外安装） - 脚本内用
cjson.encode({a = 1, b = {x = "foo"}})，而不是裸return {a = 1, b = {x = "foo"}} - 客户端统一用语言原生 JSON 库解析返回值，例如 Python 的
json.loads(resp)，不再依赖驱动的 table→list 映射 - 注意：如果返回内容含二进制数据（如图片 base64），JSON 编码会增加约 33% 体积，此时应改用 RESP3 的
blob类型或分段传输
EVAL 返回 nil 元素时，不同客户端怎么处理
Lua 中 nil 不能直接出现在 table 返回值里（{1, nil, 3} 是非法语法），但 redis.call() 失败且用 redis.pcall() 捕获时，会返回形如 {ok=false, err="..."} 的 table；若你在脚本里手动构造 {1, false, 3}，false 会被客户端当作布尔值，不是 nil。
真正要警惕的是：某些客户端（如早期 Jedis）把 RESP 中的 NULL BULK REPLY（即 $-1）映射为空字符串、null 或直接丢弃，导致长度错位。
- 永远用
redis.pcall()包裹可能失败的命令，并显式判断res[1] == false，不要依赖nil出现场景 - 避免在返回 table 中混用
nil占位（Lua 不允许），改用哨兵值如"__NIL__"，客户端再替换 - 测试时用
redis-cli --raw EVAL "..."查看原始 RESP 输出，确认$-1是否真实存在，再比对客户端实际接收值 - Go 的
github.com/go-redis/redis/v9会把$-1转为nil interface{}，但 Python redis-py 默认转成None，行为一致；问题多出在自研或老驱动上
