处理Redis Lua脚本中cmsgpack序列化报错_确保数据类型符合Pack标准

cmsgpack.pack()报错因传入非法类型，仅支持nil、布尔、数字、字符串及纯数组/字典table；须用pcall防护并预检类型，否则静默失败。

Redis Lua脚本里cmsgpack.pack()报错：常见触发场景

Redis 内置的 cmsgpack 模块不是通用 JSON 序列化器，它只接受 Lua 原生类型中“可打包”的子集。一旦传入 function、thread、含循环引用的 table、或带元表（metatable）的值，cmsgpack.pack() 就会直接报 ERR Error running script 且不提示具体字段——这是最典型的静默失败。

典型错误现象包括：

• 脚本返回 nil 或空响应，但 Redis 日志无报错
• redis.call("SET", "key", cmsgpack.pack(data)) 执行后键值为空或乱码
• 用 redis.debug(cmsgpack.pack(x)) 在 LDB 调试时崩溃退出

哪些数据能安全 pack？必须手动过滤

cmsgpack.pack() 只支持：nil、布尔、数字（int/float）、字符串、一维数组式 table（即 key 为连续正整数，且无 gap）、纯字典式 table（key 全为字符串，value 本身也必须是可 pack 类型）。任何嵌套结构都必须扁平化或预检。

实操建议：

• 用 type(v) == "table" + next(v) == nil 判断空表，避免 pack 空表引发边界异常
• 对输入 table 做两遍遍历：第一遍 for k in pairs(t) do if type(k) ~= "string" and type(k) ~= "number" then error("invalid key type") end end；第二遍检查每个 v 是否在允许类型列表内
• 禁止直接 pack 含 __index、__newindex 等元方法的 table —— 即使内容合法，cmsgpack 也会拒绝
• 数字统一转为 tonumber() 再 pack，防止字符串数字（如 "123"）被当字符串序列化

替代方案：什么时候该放弃 cmsgpack？

如果你的 Lua 脚本需要处理用户传入的任意结构（比如前端送来的嵌套 JSON），硬塞 cmsgpack 是自找麻烦。此时更稳的做法是：

• 客户端提前序列化为 JSON 字符串，Lua 脚本只做 redis.call("SET", KEYS[1], ARGV[1]) —— 把序列化责任移出 Redis
• 若必须在 Lua 侧拼装，改用 json.encode()（需 Redis 7.0+ 加载 redis.json 模块）或手写简易 JSON builder（仅限简单 flat 结构）
• 对数值型集合，优先用 Redis 原生命令：LPUSH/HSET 替代 pack 后 set，避免序列化/反序列化开销

注意：cmsgpack.unpack() 对非 cmsgpack.pack() 产出的数据（比如 Python 的 msgpack.dumps）也可能失败 —— 它认的是 Redis 自己的打包协议，不是标准 msgpack。

调试时怎么快速定位 pack 失败点？

别靠猜。在调用 cmsgpack.pack() 前加防御性打印：

local function safe_pack(data)  if type(data) == "table" then    redis.debug("packing table with keys:", table.concat({table.keys(data)}, ","))  end  local ok, res = pcall(cmsgpack.pack, data)  if not ok then    redis.error_reply("cmsgpack.pack failed on: " .. type(data))  end  return resend

关键点：

• 永远用 pcall() 包裹 cmsgpack.pack()，否则错误直接中断脚本
• table.keys() 需自己实现（遍历 pairs 收集 key），不能依赖不存在的内置函数
• 生产环境删掉 redis.debug，但保留 pcall + error_reply —— 否则你连哪一行挂了都不知道

cmsgpack 的限制不是 bug，是设计取舍。它的快，建立在“你得自己管好输入”的前提上。越早接受这点，越少半夜被 ERR Error running script 唤醒。