Redis Lua脚本cmsgpack序列化报错解决：数据类型需符合Pack标准

在Redis Lua脚本中调用 cmsgpack.pack() 出现报错，归根结底只有一个原因：传入了该函数无法识别的数据类型。这个模块仅支持 nil、布尔值、数字、字符串，以及结构清晰的纯数组或纯字典类型的 table。一旦遇到函数、线程、循环引用或带有元表的值，脚本就会直接崩溃，而且这种失败往往是静默的——不提供具体字段信息，只抛出一条 ERR Error running script，让你自己慢慢排查。

实际开发中常见的场景包括：脚本返回 nil 或空响应，但Redis日志中毫无记录；执行 redis.call("SET", "key", cmsgpack.pack(data)) 后，键值要么为空要么出现乱码；使用 redis.debug 调试时，调试器直接崩溃退出。每一种情况都足以让人头疼。

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

cmsgpack.pack() 所支持的数据类型范围其实非常有限：nil、布尔值、数字（整数或浮点数均可）、字符串、一维数组型 table（key 必须是从1开始的连续正整数，不能有缺口）、纯字典型 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；第二遍逐个检查每个 value 是否在允许的类型列表中
• 包含 __index、__newindex 等元方法的 table 应直接禁止 pack——即使内容合法，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构建器，但仅适用于简单的扁平结构
• 对于数值型集合，优先使用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 res
end

这里有几个关键点值得留意：

• 始终使用 pcall() 包裹 cmsgpack.pack()，否则错误会直接中断脚本，连挽回的机会都没有
• table.keys() 需要自己实现——遍历 pairs 收集 key，不能依赖不存在的内置函数
• 生产环境中可以去掉 redis.debug，但 pcall 加上 error_reply 必须保留，否则你连哪一行挂掉了都找不到线索

说到底，cmsgpack 的限制并不是 bug，而是设计上的一种权衡。它的高性能建立在“你必须自己管理好输入数据”这个前提之上。越早接受这个事实，就越少在半夜被 ERR Error running script 叫醒。