【性能调优】递归改写：尾调用与迭代的栈开销

实战应用：用在哪里

师徒链的层级遍历、行会职位的树状结构、嵌套菜单的展开——递归的写法优雅但栈深是隐形的雷。递归改写把深层的递归换成迭代，栈的开销从线性增长变成常数。

递归的栈险

---递归写法：师徒链的层级追溯
local function masterDepth(actor, depth)
    local m = getplayvar(actor, 2, "MasterName")
    if not m or m == "" then
        return depth
    end
    return masterDepth(m, depth + 1)   -- 每层一层栈
end

---深链的现场：千层师徒链（数据异常）直接爆栈

递归的每层调用压一层栈：师徒链的数据异常（互相拜师形成环）让递归深入千层，栈溢出的报错把整个调用链带崩。递归的改写有两条路：尾调用的形态（递归调用是函数的收尾一步）在 Lua 的尾调用优化下栈深恒定；通用的迭代化用循环加显式栈替代隐式的调用栈。

迭代的改写

---迭代化：显式栈替代调用栈
local function masterDepthIter(actor)
    local depth = 0
    local cur = actor
    local seen = {}
    while true do
        local m = getplayvar(cur, 2, "MasterName")
        if not m or m == "" or seen[m] then
            return depth
        end
        seen[m] = true            -- 环的检测
        cur = m
        depth = depth + 1
        if depth > 50 then
            return depth          -- 层数上限的保险
        end
    end
end

迭代化的三件套：循环体替代递归体、显式的状态变量（depth 与 cur）替代参数传递、环的检测（seen 表）替代栈溢出的被动报错。改写后的版本在数据异常的现场表现优雅：环被识别为层数 0 的返回，50 层的上限是数据异常的保险丝——优雅的代码在脏数据面前也要站得住。尾调用的识别有严格的条件：return f(x) 的直接返回形态才被优化，return f(x) + 1 的形态不优化——依赖尾调用的改写要确认形态，拿不准就用显式循环的通用解。递归的保留场景：树的层数有限且确认无环（装备的镶嵌树最多 3 层），递归的可读性优先。

验证与监控

改写前后的行为等价测试：正常链、深链、环链三种数据形态的结果比对；栈层数的监控（debug.traceback 的抽样统计），深栈的调用链进性能的观察名单。

踩坑记录

尾调用的改写曾经想当然，return 1 + masterDepth(...) 的形态不被优化，栈照炸，显式循环的通用解替代。环的检测曾经用层数上限替代，上限设 500 的版本里 500 层的环把延迟拖到秒级，seen 表的主动检测替代被动上限。迭代的显式栈曾经在多返回值间漏传，状态的携带不全让结果错，状态的清单化管理。

上线要点

递归的规范进代码评审：层数不可预估的递归一律改写。栈的溢出报错进错误的聚合监控，递归的雷爆一次就要清一类。改写的等价性测试进公共库的模板，迭代的改造有测试兜底。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。