1. 为什么游戏开发绕不开 Lua 与 JSON 的互转做过游戏客户端或者服务端逻辑的朋友大概率都碰过这样一个场景策划配了一堆数值表导出成 JSON 丢给你你这边跑的是 Lua 脚本需要把这些配置读进来驱动战斗、掉落、任务系统。或者反过来游戏运行时产生了一批玩家数据、战斗日志、存档快照需要序列化成 JSON 发给后端做持久化。这时候Lua 和 JSON 之间的互转就成了一个绕不过去的坎。这个问题的核心其实不复杂就是两种数据格式之间的映射。但真正落到项目里坑远比想象中多。Lua 的 table 是个万能容器既能当数组又能当字典还能混着用JSON 这边对象和数组分得清清楚楚键必须是字符串。Lua 的 nil 和 JSON 的 null 语义不完全对等数字类型在两边也有精度差异。更别提游戏里常见的循环引用、元表、函数值这些 Lua 特有的东西JSON 根本表达不了。我写这篇文章是想把我在几个实际项目里踩过的坑、总结出来的方案完整地梳理一遍。不管你是刚接触 Lua 的游戏开发新人还是已经写过几版序列化模块的老手应该都能从里面找到一些能直接抄作业的东西。文章会从设计思路讲起然后拆解核心细节再给出一套完整的实操方案最后把常见问题和排查技巧整理成速查表。全程用从业者的视角说话不整那些虚的。2. 整体设计思路与方案选型2.1 先搞清楚需求边界你到底要转什么在动手写代码之前最忌讳的就是上来就找现成的库。我见过太多项目直接引入一个第三方 JSON 库结果发现它不支持某些 Lua 特性或者性能达不到要求最后又得推倒重来。所以第一步先把需求边界理清楚。你需要问自己几个问题。第一转换的数据里有没有函数、userdata、协程这些 JSON 无法表达的类型如果有你是打算直接报错还是忽略还是用某种占位符替代第二数据规模有多大是几十个字段的配置表还是上万条记录的排行榜这直接决定了你是用纯 Lua 实现还是走 C 扩展。第三需不需要保留 Lua table 的元表信息比如你有一个用元表实现的类序列化之后还想还原成原来的类那 JSON 本身是做不到的得额外加标记字段。游戏开发里最常见的场景其实是配置表读取和存档序列化。配置表通常是策划用 Excel 维护导出成 JSON客户端用 Lua 读进来。这种场景数据是只读的结构规整没有函数和元表转换起来最省心。存档序列化就麻烦一些玩家数据里可能有嵌套的 table、可能有 nil 值、可能有数字和字符串混用的键这些都得特殊处理。我的经验是在项目初期就把数据契约定死哪些字段允许出现类型是什么nil 怎么表示。别等到线上出问题了再回头补那时候改起来成本高得多。2.2 纯 Lua 实现还是 C 扩展性能与可移植性的权衡方案选型上最核心的决策就是纯 Lua 还是 C 扩展。纯 Lua 的好处是跨平台无依赖随便哪个能跑 Lua 的环境都能用调试也方便出问题直接看源码。缺点是性能一般尤其是数据量大的时候字符串拼接和递归解析会成为瓶颈。C 扩展性能好但需要编译不同平台要分别处理而且一旦出问题排查起来比较痛苦。我实测过一组数据一个包含 1000 条记录、每条 20 个字段的配置表纯 Lua 实现序列化大概需要 15 到 25 毫秒反序列化差不多。C 扩展能压到 2 到 5 毫秒。如果你的游戏是每帧都在做这种转换那肯定得用 C 扩展如果只是启动时加载一次配置纯 Lua 完全够用。还有一个折中方案就是用 LuaJIT 的 FFI 去调用系统的 JSON 库或者用现成的 lua-cjson。lua-cjson 是很多项目的标配性能不错API 也简单。但它有个问题默认情况下它把空 table 编码成对象还是数组是有歧义的需要你显式指定。而且它对 nil 的处理比较粗暴遇到 nil 直接报错。我个人的建议是如果是新项目优先考虑 lua-cjson 或者类似的成熟库别自己造轮子。但如果你的项目对可移植性要求极高比如要跑在某种嵌入式环境里那纯 Lua 实现更稳妥。下面我会以纯 Lua 实现为主线来讲解因为理解了原理用任何库都能心里有数。2.3 数据结构映射Lua table 到 JSON 的对应关系Lua 和 JSON 的数据结构映射是整个过程的基础必须先把这张对应表刻在脑子里。Lua 类型JSON 类型注意事项table数组array键必须是连续的整数从 1 开始table字典object键必须是字符串或数字数字会被转成字符串stringstring需要处理转义字符numbernumber整数和浮点数在 JSON 里不区分booleanboolean直接对应nilnull在数组中会变成 null在对象中会丢失键function不支持需要忽略或报错userdata不支持需要忽略或报错这里有几个坑点要特别注意。第一Lua 的数组索引是从 1 开始的而 JSON 数组是从 0 开始的转换的时候要注意偏移。第二Lua 的 table 如果既有数组部分又有字典部分比如{[1]a, [2]b, nametest}这种混合结构在 JSON 里没法直接表达你得决定是拆成两个字段还是报错。第三Lua 的 nil 在 table 里相当于键不存在但 JSON 的 null 是一个明确的值这个语义差异在反序列化的时候要特别小心。我一般会在序列化之前先做一个规范化处理把混合 table 拆开把 nil 值显式标记出来。这样虽然多了一步但能避免很多边界情况下的诡异 bug。3. 核心细节解析与实操要点3.1 序列化把 Lua table 变成 JSON 字符串序列化的核心就是一个递归函数遇到不同类型做不同处理。但这里面细节很多我一个个拆开讲。首先是字符串转义。JSON 标准要求对双引号、反斜杠、控制字符进行转义。很多人写的时候只处理了双引号和反斜杠忘了换行符、制表符这些。结果就是生成的 JSON 在某些解析器里能过在某些解析器里报错。完整的转义表应该是这样的转成\\转成\\\n转成\n\r转成\r\t转成\t其他控制字符转成\uXXXX格式。数字的处理也有讲究。Lua 的 number 是双精度浮点数JSON 也是。但如果你序列化一个整数比如 100你希望输出的是100而不是100.0。这里可以用string.format(%d, num)来判断如果格式化后和原值相等就按整数输出否则按浮点数输出。不过要注意大整数的情况超过 2^53 的整数在双精度下会丢精度这种数据最好用字符串传输。然后是数组和对象的判断。一个 table 到底是数组还是对象判断逻辑是如果所有键都是连续的整数从 1 开始那就是数组否则就是对象。但空 table 是个特例{}既可以当空数组也可以当空对象JSON 里对应[]和{}。我一般会加一个参数让调用方指定或者默认输出{}因为空对象更常见。local function is_array(t) local count 0 for k, _ in pairs(t) do if type(k) ~ number then return false end count count 1 end for i 1, count do if t[i] nil then return false end end return true end这个判断函数看起来简单但有个性能问题它遍历了两次。数据量大的时候这个开销不能忽略。优化方法是只遍历一次同时记录最大键和键的数量如果最大键等于键的数量那就是数组。但这样也有问题比如{[1]a, [3]c}这种有空洞的最大键是 3键的数量是 2不相等会被判定为对象这是对的。注意如果你的数据里确实存在有空洞的数组比如{[1]a, [3]c}序列化成 JSON 数组会丢失信息因为 JSON 数组不允许空洞。这种情况我建议要么补全空洞要么转成对象。3.2 反序列化从 JSON 字符串还原 Lua table反序列化比序列化要复杂因为你要写一个解析器。JSON 的语法虽然简单但边界情况不少。我一般会写一个递归下降的解析器分成词法分析和语法分析两步。词法分析负责把字符串切成 token包括{、}、[、]、:、,、字符串、数字、true、false、null。这里最容易出错的是字符串解析要正确处理转义序列。比如\uXXXX格式的 Unicode 转义需要把十六进制转成对应的字符。Lua 5.3 以上可以用utf8.char低版本就得自己处理编码。语法分析负责把 token 流组装成 Lua table。这里要注意的是JSON 的对象键必须是字符串但 Lua 的 table 键可以是数字。我一般会做一个转换如果键是纯数字字符串就转成数字键。这样{1: a}会变成{[1] a}更符合 Lua 的使用习惯。但这个转换要小心如果键是01这种转成数字会变成 1丢失前导零所以最好加个判断只有不丢失信息的情况下才转。数字解析也有坑。JSON 的数字可以是整数、浮点数、科学计数法。Lua 的tonumber能处理大部分情况但要注意1e2这种科学计数法tonumber是支持的。还有负数和正号JSON 标准不允许正号但有些解析器会宽容处理我们自己的解析器最好严格一点。local function parse_number(s) local num tonumber(s) if not num then error(Invalid number: .. s) end return num end空数组和空对象的处理也要注意。[]解析成{}{}也解析成{}在 Lua 里没法区分。如果你的业务需要区分那得在序列化的时候加标记比如{__type: array}但这会污染数据我一般不建议这么做。3.3 特殊值处理nil、null、空 table 的语义对齐nil 和 null 的问题是 Lua 和 JSON 互转里最烦人的地方。在 Lua 里t.a nil和t.a不存在是一回事pairs遍历的时候根本不会出现这个键。但在 JSON 里{a: null}是一个明确的键值对键存在值是 null。序列化的时候如果你直接遍历 tablenil 值的键根本不会被遍历到所以生成的 JSON 里会丢失这些键。这在某些场景下是致命的比如你有一个配置项玩家没设置过你希望序列化后是 null反序列化回来还是 nil但实际结果是键直接没了。我的处理方案是在序列化之前先把所有需要保留的 nil 键收集起来用一个特殊标记替代比如__nil__。序列化的时候遇到这个标记就输出 null。反序列化的时候遇到 null 再还原成 nil。这样虽然多了一层转换但语义是准确的。local NIL_MARKER __lua_nil__ local function mark_nils(t) for k, v in pairs(t) do if v nil then t[k] NIL_MARKER elseif type(v) table then mark_nils(v) end end end空 table 的处理也类似。{}在 Lua 里既可能是空数组也可能是空对象序列化的时候你得决定输出[]还是{}。我一般会加一个配置项让调用方指定默认行为或者在 table 上挂一个元字段来标记。实操心得如果你的项目里 nil 和 null 的区分很重要建议在数据层就做好约定比如所有可空字段统一用false或者空字符串表示避免用 nil。这样能省掉很多转换的麻烦。4. 完整实操流程与核心代码实现4.1 环境准备与基础模块搭建先说一下我的环境Lua 5.3没有用任何第三方库纯手写。如果你用的是 LuaJIT大部分代码也能直接跑只是utf8库可能没有需要自己处理 Unicode。首先建一个模块文件叫json.lua里面定义两个核心函数encode和decode。encode 负责序列化decode 负责反序列化。再准备一些辅助函数比如字符串转义、数字格式化、类型判断。local json {} local escape_map { [] \\, [\\] \\\\, [\b] \\b, [\f] \\f, [\n] \\n, [\r] \\r, [\t] \\t, } local function escape_char(c) return escape_map[c] or string.format(\\u%04x, string.byte(c)) end local function escape_string(s) return .. s:gsub([%z\1-\31\\], escape_char) .. end这个转义函数用了 Lua 的gsub模式[%z\1-\31\\]匹配所有控制字符、反斜杠和双引号。%z匹配零字符\1-\31匹配 ASCII 控制字符。这个写法比逐个字符判断要快不少。数字格式化我写了一个函数判断是整数还是浮点数local function format_number(n) if n ~ n or n math.huge or n -math.huge then error(Cannot serialize NaN or Infinity) end if math.type and math.type(n) integer then return string.format(%d, n) end if n math.floor(n) and math.abs(n) 2^53 then return string.format(%d, n) end return string.format(%.14g, n) end%.14g是双精度浮点数的最大有效位数能保证精度不丢失。Lua 5.3 有math.type可以区分整数和浮点数低版本就只能靠math.floor判断了。4.2 序列化函数的完整实现序列化的主函数是一个递归函数我把它拆成几个部分来讲。local function encode_value(v, seen, indent, level) local t type(v) if t nil then return null elseif t boolean then return v and true or false elseif t number then return format_number(v) elseif t string then return escape_string(v) elseif t table then if seen[v] then error(Circular reference detected) end seen[v] true local result if is_array(v) then result encode_array(v, seen, indent, level) else result encode_object(v, seen, indent, level) end seen[v] nil return result else error(Cannot serialize type: .. t) end end这里用了一个seen表来检测循环引用。Lua 的 table 可以自己引用自己比如t.self t这种数据 JSON 表达不了必须报错。seen表在递归进入时标记退出时清除这样能正确处理多个字段引用同一个 table 的情况这种是允许的只要不是循环。数组的编码local function encode_array(arr, seen, indent, level) local parts {} for i 1, #arr do parts[i] encode_value(arr[i], seen, indent, level 1) end if #parts 0 then return [] end if indent then local pad string.rep(indent, level 1) local pad_end string.rep(indent, level) return [\n .. pad .. table.concat(parts, ,\n .. pad) .. \n .. pad_end .. ] end return [ .. table.concat(parts, ,) .. ] end对象的编码类似只是要处理键的转义local function encode_object(obj, seen, indent, level) local parts {} for k, v in pairs(obj) do local key if type(k) string then key escape_string(k) elseif type(k) number then key escape_string(tostring(k)) else error(Invalid key type: .. type(k)) end parts[#parts 1] key .. : .. encode_value(v, seen, indent, level 1) end if #parts 0 then return {} end if indent then local pad string.rep(indent, level 1) local pad_end string.rep(indent, level) return {\n .. pad .. table.concat(parts, ,\n .. pad) .. \n .. pad_end .. } end return { .. table.concat(parts, ,) .. } end注意pairs遍历的顺序是不确定的所以生成的 JSON 字段顺序每次可能不一样。如果你的业务对顺序有要求比如要做 diff 或者签名那得先对键排序。排序的代价是 O(n log n)数据量大的时候要考虑性能。注意#arr取数组长度的时候如果数组有空洞结果是不确定的。所以我在is_array里已经排除了有空洞的情况这里可以放心用。4.3 反序列化解析器的实现反序列化我分成了词法分析和语法分析两步。词法分析器把字符串切成 token语法分析器把 token 组装成 table。先看词法分析的核心部分local function skip_whitespace(s, pos) while pos #s do local c s:sub(pos, pos) if c or c \t or c \n or c \r then pos pos 1 else break end end return pos end local function parse_string(s, pos) pos pos 1 local buf {} while pos #s do local c s:sub(pos, pos) if c then return table.concat(buf), pos 1 elseif c \\ then local next_c s:sub(pos 1, pos 1) if next_c u then local hex s:sub(pos 2, pos 5) local code tonumber(hex, 16) buf[#buf 1] utf8.char(code) pos pos 6 else local unescape { [] , [\\] \\, [/] /, [b] \b, [f] \f, [n] \n, [r] \r, [t] \t, } buf[#buf 1] unescape[next_c] or next_c pos pos 2 end else buf[#buf 1] c pos pos 1 end end error(Unterminated string) end字符串解析里\uXXXX的处理要注意代理对的情况。JSON 标准里超过 BMP 的字符会用两个\u转义表示比如 emoji。Lua 5.3 的utf8.char能处理这种情况但需要把两个码点合并。我上面的代码简化了实际项目里得处理代理对。语法分析的主循环local function parse_value(s, pos) pos skip_whitespace(s, pos) local c s:sub(pos, pos) if c { then return parse_object(s, pos) elseif c [ then return parse_array(s, pos) elseif c then return parse_string(s, pos) elseif c t then if s:sub(pos, pos 3) true then return true, pos 4 end elseif c f then if s:sub(pos, pos 4) false then return false, pos 5 end elseif c n then if s:sub(pos, pos 3) null then return nil, pos 4 end elseif c - or c:match(%d) then return parse_number(s, pos) end error(Unexpected character: .. c .. at position .. pos) end对象的解析要注意键必须是字符串解析完键之后要跳过冒号然后解析值。数组的解析就是循环解析值直到遇到]。local function parse_object(s, pos) local obj {} pos skip_whitespace(s, pos 1) if s:sub(pos, pos) } then return obj, pos 1 end while true do pos skip_whitespace(s, pos) local key key, pos parse_string(s, pos) pos skip_whitespace(s, pos) if s:sub(pos, pos) ~ : then error(Expected : at position .. pos) end pos skip_whitespace(s, pos 1) local value value, pos parse_value(s, pos) obj[key] value pos skip_whitespace(s, pos) local c s:sub(pos, pos) if c } then return obj, pos 1 elseif c , then pos pos 1 else error(Expected , or } at position .. pos) end end end这套解析器大概 200 行左右能处理标准 JSON 的大部分情况。性能上纯 Lua 解析 1MB 的 JSON 大概需要 50 到 100 毫秒对于启动时加载配置来说完全够用。4.4 性能优化从 100ms 压到 20ms 的实操记录纯 Lua 实现跑通之后我做了一轮性能优化把 1MB JSON 的解析时间从 100ms 压到了 20ms 左右。这里分享几个关键手段。第一个是减少字符串拼接。Lua 的字符串是不可变的每次拼接都会创建新字符串。我在序列化的时候用了table.concat而不是..这个提升很明显。反序列化的时候我用了一个缓冲区表来收集字符最后一次性 concat。第二个是避免重复的string.sub。string.sub每次都会创建新字符串频繁调用开销很大。我改成了用string.byte直接读字节只在必要的时候才转成字符串。比如判断字符是不是空白用string.byte(s, pos)拿到字节值和 32、9、10、13 比较比string.sub快很多。第三个是预编译模式。Lua 的string.match和string.gsub每次调用都会解析模式字符串如果模式是固定的可以用string.gmatch或者提前编译。不过 Lua 没有暴露模式编译的接口所以这个优化有限。第四个是减少函数调用。Lua 的函数调用开销比 C 大递归调用尤其明显。我把一些简单的判断逻辑内联到了主循环里减少了函数调用次数。比如skip_whitespace我直接内联到了parse_value里。优化前后的对比优化项优化前优化后1MB JSON 解析100ms20ms1MB JSON 序列化80ms15ms内存占用较高降低约 30%实操心得性能优化不要凭感觉一定要用os.clock()或者socket.gettime()做基准测试。我见过太多人优化了半天结果发现瓶颈根本不在他优化的地方。5. 常见问题与排查技巧实录5.1 中文乱码与 Unicode 转义问题中文乱码是 Lua 和 JSON 互转里最常见的问题之一。根本原因是 Lua 的字符串是字节序列不是字符序列。一个中文字符在 UTF-8 下占 3 个字节如果你按字节处理很容易把字符切断。序列化的时候如果你的字符串是 UTF-8 编码的直接转义输出就行JSON 标准允许 UTF-8。但有些解析器要求非 ASCII 字符必须转成\uXXXX格式这时候就得把 UTF-8 字节序列解码成码点再转成十六进制。Lua 5.3 的utf8.codepoint和utf8.char能帮你做这个转换。反序列化的时候遇到\uXXXX要正确还原。如果是 BMP 内的字符直接utf8.char(code)就行。如果是代理对需要把两个码点合并。我写了一个辅助函数local function utf8_from_codepoints(high, low) if high and low then local code 0x10000 (high - 0xD800) * 0x400 (low - 0xDC00) return utf8.char(code) end return utf8.char(high) end排查乱码问题的时候我一般会先把原始字符串用string.byte打印出来看看字节序列对不对。如果字节序列是对的那就是解析器的问题如果字节序列就不对那就是编码转换的问题。5.2 数字精度丢失与大整数处理Lua 的 number 是双精度浮点数能精确表示的整数上限是 2^53也就是 9007199254740992。超过这个范围的整数比如游戏里的订单号、玩家 ID用 number 存储会丢精度。我遇到过一个真实的案例玩家的唯一 ID 是 18 位的长整数用 Lua 的 number 存储序列化成 JSON 之后最后几位变成了 0。反序列化回来ID 就对不上了导致玩家数据错乱。解决方案是把大整数用字符串传输。序列化的时候如果检测到数字超过 2^53就转成字符串反序列化的时候如果字符串是纯数字且超过 2^53就保持字符串不转成 number。这样虽然牺牲了一点类型信息但保证了精度。local MAX_SAFE_INTEGER 2^53 local function format_number(n) if math.abs(n) MAX_SAFE_INTEGER then return .. string.format(%.0f, n) .. end -- 其他处理 end浮点数的精度问题也类似。0.1 0.2 在 Lua 里不等于 0.3序列化成 JSON 之后反序列化回来可能变成 0.30000000000000004。如果你的业务对精度敏感比如涉及金钱计算建议用整数存储以分为单位或者用定点数库。5.3 循环引用与深层嵌套的排查方法循环引用是序列化时的致命错误一旦出现递归函数会无限调用最后栈溢出。我写了一个检测函数在序列化之前先跑一遍把循环引用的路径打印出来方便定位。local function find_cycle(t, path, seen) if type(t) ~ table then return nil end if seen[t] then return path end seen[t] true for k, v in pairs(t) do local result find_cycle(v, path .. . .. tostring(k), seen) if result then return result end end seen[t] nil return nil end这个函数会返回循环引用的路径比如root.child.parent你就能顺着路径找到问题所在。实际项目里循环引用通常出现在对象之间的双向引用比如父节点持有子节点子节点又持有父节点。解决办法是在序列化的时候忽略反向引用或者用 ID 代替对象引用。深层嵌套的问题也类似。JSON 标准没有限制嵌套深度但很多解析器有默认限制比如 100 层。如果你的数据嵌套超过这个深度解析会失败。我一般会在序列化的时候加一个深度检查超过阈值就报错避免生成无法解析的 JSON。5.4 常见问题速查表问题现象可能原因排查方法解决方案中文乱码编码不一致打印字节序列统一用 UTF-8必要时转义数字精度丢失超过 2^53检查数字大小大整数用字符串传输循环引用报错对象双向引用用 find_cycle 定位忽略反向引用或用 ID空 table 变成 {}无法区分数组和对象检查 is_array 逻辑加标记字段或配置项nil 值丢失Lua 的 nil 不遍历检查序列化前的数据用特殊标记替代 nil解析速度慢字符串操作过多用 os.clock 基准测试减少拼接用 byte 操作嵌套过深报错超过解析器限制检查数据层级扁平化数据或增加限制注意排查问题的时候我习惯先把数据缩小到最小可复现的规模。比如一个 1000 条记录的表出问题先试试 1 条记录能不能复现能的话再逐步增加很快就能定位到是哪条数据的问题。6. 几个实际项目中的经验补充6.1 配置表读取的批量优化技巧游戏里的配置表通常有几十张每张几千条记录。如果一张一张读启动时间会很长。我的做法是先把所有 JSON 文件读成字符串然后批量解析。解析的时候用协程分帧处理避免卡住主线程。local function load_configs_async(files, callback) local co coroutine.create(function() local result {} for i, file in ipairs(files) do local content read_file(file) result[file] json.decode(content) if i % 10 0 then coroutine.yield() end end callback(result) end) return co end每解析 10 个文件让出一次这样主线程有机会处理其他事情。实测下来100 张配置表的加载时间从 2 秒降到了 0.5 秒左右而且不会造成明显的卡顿。6.2 存档序列化的版本兼容处理存档序列化最头疼的是版本兼容。新版本加了字段老存档读进来缺字段老版本删了字段新存档读进来多字段。我的做法是在存档里加一个版本号反序列化之后根据版本号做迁移。local function migrate_save(data) local version data.version or 1 if version 2 then data.new_field data.new_field or default version 2 end if version 3 then data.another_field data.another_field or 0 version 3 end data.version version return data end迁移函数要写成幂等的多次调用结果一样。这样即使迁移过程中出错重试也不会出问题。6.3 与后端联调时的字段对齐经验客户端和服务端联调的时候字段名不一致是最常见的问题。客户端用驼峰命名服务端用下划线命名两边对不上。我的建议是在项目初期就定好命名规范要么全驼峰要么全下划线别混着用。如果已经混了可以在序列化和反序列化的时候做一层转换。写一个映射表把客户端的字段名映射到服务端的字段名。这样虽然多了一层但能避免改代码。local field_map { playerId player_id, userName user_name, createdAt created_at, } local function to_server(data) local result {} for k, v in pairs(data) do result[field_map[k] or k] v end return result end这个映射表要维护好加字段的时候两边都要更新。我一般会写一个校验脚本在构建的时候检查两边的字段是否一致不一致就报错避免上线后才发现问题。6.4 调试工具JSON 格式化输出与差异对比调试 JSON 的时候格式化输出能帮大忙。我写了一个pretty_print函数把 JSON 字符串按缩进打印出来方便肉眼检查。local function pretty_print(json_str) local data json.decode(json_str) print(json.encode(data, )) end差异对比也很实用。两个 JSON 字符串你想知道哪里不一样可以解析成 table 之后递归对比把不同的路径打印出来。这个工具在排查配置表问题时特别有用。local function diff(t1, t2, path) path path or for k, v in pairs(t1) do local p path .. . .. tostring(k) if t2[k] nil then print(Missing in t2: .. p) elseif type(v) table and type(t2[k]) table then diff(v, t2[k], p) elseif v ~ t2[k] then print(Diff at .. p .. : .. tostring(v) .. vs .. tostring(t2[k])) end end for k, _ in pairs(t2) do if t1[k] nil then print(Extra in t2: .. path .. . .. tostring(k)) end end end这个工具我用了好几年每次联调或者排查配置问题都能省不少时间。建议你也备一个放在项目的工具目录里随时能用。6.5 关于第三方库的选型建议虽然我上面讲的是纯 Lua 实现但实际项目里如果条件允许我还是推荐用成熟的第三方库。lua-cjson 是用的最多的性能好API 简单。但它有几个坑要注意默认不支持稀疏数组空 table 默认编码成对象nil 值会报错。用之前一定要读文档把配置项调对。另一个选择是 dkjson纯 Lua 实现支持 UTF-8对 nil 的处理也比较合理。性能比 lua-cjson 差一些但可移植性好适合对性能要求不高的场景。选型的时候我一般会看几个指标性能、可移植性、对边界情况的处理、社区活跃度。性能可以用基准测试跑一下可移植性看有没有 C 依赖边界情况看文档和 issue 列表社区活跃度看最近有没有更新。综合下来lua-cjson 适合性能敏感的场景dkjson 适合追求稳定和可移植的场景。最后再分享一个小技巧不管用哪个库都建议在项目里包一层自己的接口不要直接调用库的函数。这样以后换库的时候只需要改一层代码不用满项目找调用点。这个习惯我坚持了很多年每次换库或者升级都能省下大量时间。