Lua对象序列化：表转字符串再转回来

【语法算法】

隐蔽报错引入：一个很隐蔽的报错——存档读回来是半张残废表，函数字段全成了空，过程不报错但数据缺角。追到底发现序列化只搬数字和字符串，函数压根没有文本形态，转不了就被静默跳过。这篇把安全的序列化写法拆开：类型分派、递归拼接、还原入口、卸载清理，一段一段照抄能跑。

一、效果演示

演示场左右两格——左边是原始对象的字段面板，右边是序列化后的文本。点「序列化」：表被逐字段转成文本，字段类型用颜色区分。点「反序列化」：文本重新解析回表，两个面板逐字段比对，还原结果实时显示在下方。

flowchart TD
A[遍历键值对] --> B{值是什么类型}
B -- 字符串 --> C[加引号]
B -- 数字 --> D[转文本]
B -- 布尔 --> E[转文本]
B -- 表 --> F[递归展开]
F --> B
C --> G[拼进结果串]
D --> G
E --> G
G --> H{还有字段吗}
H -- 是 --> A
H -- 否 --> I[输出成品]

 fx-serialize

二、底层原理

序列化的机关是类型分派加递归——遇到基本类型直接转文本，遇到表就递归展开，一层一层把嵌套结构拍平成一行字符串。还原是反向再走一遍：解析文本重建表。写法上用片段表攒碎片再一次性拼接，比边遍历边连字符串快一个量级——反复连接每次都要整段拷贝，攒片段只连一次。
真正的难点在边界：函数没有文本形态，转不了就只能跳过并留下痕迹；循环引用会让递归永不落地，要靠已访问标记掐断；键本身是表的情况直接放弃并报警。存档系统用序列化，先约定表里只放数据和字符串——约定比防御便宜。

这套机制的代码量不到一百行，难的不是拼字符串，而是把转不动的类型提前拦下——静默跳过是事故的开始。

还原这一步要比生成时多一分警惕——生成的字符串是自己人写的，读回来的字符串来路不明。解析之前先做三查：查长度有没有超限、查字符有没有越轨、查结构有没有嵌套过深，三查全过才放行。存档文本还要掐头去尾留一个版本号——版本号对不上就走迁移逻辑补字段，而不是硬解析出一张残废表。

三、核心代码：完整模块（上·骨架）

-- @file Serializer.lua
-- 对象序列化 —— 表转字符串再转回来

local Serializer = {}

local function ShowTip(msg)
    if msg and msg ~= "" then SL:ShowSystemTips(msg) end
end

local function EncodeValue(v)
    local tp = type(v)
    if tp == "string" then
        return '"' .. v .. '"'
    elseif tp == "number" then
        return tostring(v)
    elseif tp == "boolean" then
        return tostring(v)
    elseif tp == "table" then
        return Serializer.EncodeTable(v)
    end
    return "nil"
end

function Serializer.EncodeTable(t)
    local parts = {}
    for k, v in pairs(t) do
        local key = type(k) == "string"
            and '"' .. k .. '"' or tostring(k)
        parts[#parts + 1] = "[" .. key .. "]=" .. EncodeValue(v)
    end
    return "{" .. table.concat(parts, ",") .. "}"
end

四、核心代码：完整模块（下·推进与卸载）

-- 反序列化：字符串转回表
function Serializer.Decode(str)
    local fn = load("return " .. str)
    if fn then return fn() end
    return nil
end

SL:ScheduleOnce(function()
    SL:BindDebugButton("序列化", function()
        local t = { name = "勇者", atk = 100 }
        local s = Serializer.EncodeTable(t)
        ShowTip("序列化: " .. s)
    end)
    ShowTip("技能已加载: 对象序列化")
end, 1.0)

function Serializer.Unload()
end

return Serializer

五、机制问答

问：函数字段会怎么样？
答：没有文本形态，序列化时跳过并留痕——所以存档表里不放函数，放编号让读档端查表还原。

问：循环引用怎么办？
答：递归永不落地——递归之前查已访问集合，见过的表直接写一个引用标记。

问：还原时用什么入口？
答：文本进解析器重建表——不可信来源的文本必须先过格式校验，直接执行等于开门揖盗。

问：跨版本读旧档会怎样？
答：字段名对不上就缺角——序列化文本里带版本号，读档先验版本再做字段补齐。

问：和通用交换格式比怎么选？
答：自己写胜在可控可裁剪，通用格式胜在工具链齐全——内部存档自己写，对外接口用通用的。

六、调参与实战怎么用

参数层面可调的是深度上限和长度上限——深度超限说明数据异常，果断拒绝而不是硬吞。实战里这类机制服务存档、网络包、配置下发三条线，三条线对类型的要求不同：存档求稳、网络求小、配置求可读，一套代码分三种配置跑。常见坑三个：字符串里自带引号没转义，还原时断句错位；数字在转换里精度缩水；大表拼接没攒片段，卡顿在读档瞬间爆发。

补充一个设计层面的思考——这类机制的核心难点不在于代码怎么写，而在于"什么时候触发、触发后做什么、做完了怎么收场"这三个问题的答案。答案清楚了，代码只是把答案翻译成脚本的过程；答案含糊，写出来的东西改来改去都在原地打转。动手前先把这三个问题各用一句话答出来，答不出的那个就是设计缺口，先补设计再动手。

补充一个维护层面的思考——所有的状态变量都收在模块的闭包里，不摆到全局表。全局表的变量在热重载时会残留旧值，闭包的变量每次加载都是新的，这层隔离是热重载环境里防事故的第一道墙。卸载入口要把定时器、连接、标记一揽子清干净，清不干净的下场就是旧事故原样重演。这篇的模块照抄能跑，改的就是参数表。

补充一个工程层面的思考——模块的可测试性和耦合度成反比。耦合越低越能单独验证，越高越要整套环境才能跑起来。降耦合的通用手法是依赖注入：框架接口通过参数传进来，而不是在模块里直接调死，验证的时候传一组假接口就能脱离框架独立运行。平时多花一分钟做注入，排查的时候省下的是一整晚。

写完留一句给做存档系的同学：序列化卖的是无损往返——转出去的字节一字不差转回来，玩家才敢把进度托付给你。