【Lua实战】unpack 的性能边界与数组分段

实战应用：用在哪里

unpack（5.3 后叫 table.unpack）把数组摊开成一串独立参数，消息转发、变参透传、批量调用都靠它。它的开销与数组长度线性相关，长数组的整包摊开是隐蔽的性能坑，分段的用法让成本可控。

边界的实测

---不同长度 unpack 的耗时对比
local function bench(n)
    local t = {}
    for i = 1, n do t[i] = i end
    local fn = function(...) return select("#", ...) end
    local t0 = os.clock()
    for _ = 1, 10000 do fn(table.unpack(t, 1, n)) end
    return (os.clock() - t0) * 1000
end

print("10 元素:", bench(10), "ms")
print("100 元素:", bench(100), "ms")
print("1000 元素:", bench(1000), "ms")
-- 10: 4ms   100: 38ms   1000: 380ms   （量级示意）

unpack 的成本随元素数线性上涨：千元素数组的万次摊开要数百毫秒，十元素只要几毫秒。摊开的本质是把数组逐个压进调用栈，栈深与数组长度成正比——超长数组还有栈溢出的硬风险，数千元素的摊开在部分环境直接报错。经验边界：几十元素以内随便用，几百元素评估调用频次，千元素以上必须分段。

分段的用法

---长数组分段摊开：每段 64 个
local SEG = 64
function Batch.forward(fn, arr)
    local n = #arr
    for from = 1, n, SEG do
        local to = math.min(from + SEG - 1, n)
        fn(table.unpack(arr, from, to))
    end
end

---消息批量转发：每段一次调用
function Relay.push(handler, queue)
    Batch.forward(function(...)
        local cnt = select("#", ...)
        handler(queue.head, cnt, ...)
    end, queue.items)
end

分段摊开把千元素的整包拆成十六段 64 元素的调用，每段的栈深可控，单段的耗时进入微秒档。分段的处理逻辑需要按段重组——消息转发场景里，处理器按段接收批量数据，段的边界用首参数携带的信息对齐。与 select 的配合：段内用 select("#") 数清参数个数，nil 尾巴在段内也被完整计数。热路径的另一个选择是干脆不摊开：传表本身比摊开再收集便宜一个数量级，摊开只在接口签名必须散参时使用。

验证与监控

unpack 调用的长度分布埋点，超 200 元素的摊开占比进性能周报；分段函数的段边界单测：长度恰为段整倍数、尾段残缺、空数组三种边界。

踩坑记录

整包摊开曾经在配置装载时用，3000 行的配置表摊开传参直接栈溢出，分段重写后正常。unpack 的第二第三参数曾经省略，默认 1 到 #t 在含 nil 的表上截短，显式传边界。5.1 与 5.3 的函数名差异（unpack 与 table.unpack）让兼容层出过双份代码，统一的包装函数收口。

上线要点

摊开的长度红线进编码规范：200 元素强制分段。消息队列的批量转发统一走分段工具函数，各业务的摊开写法收口。基准数据随引擎升级重测，红线数值用数据说话。

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