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

Redis Lua脚本中使用cmsgpack.pack()报错，原因归结为一点：传入了该模块不认可的数据类型。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为连续正整数，无缺口）、纯字典式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 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 res
end

这里有几个关键点需要留意：

• 始终使用pcall()包裹cmsgpack.pack()，否则错误会直接中断脚本，无法挽回。
• table.keys()需要自行实现——遍历pairs收集key，不能依赖不存在的内置函数。
• 生产环境可删除redis.debug，但pcall加上error_reply必须保留，否则无法定位具体哪一行出错。

整体而言，cmsgpack的限制并非bug，而是设计上的一种取舍。它的高效率建立在“需要自己管理输入”的前提之上。越早接受这一事实，越能减少被ERR Error running script困扰的情况。