【性能调优】字符串与 table 的性能细节：避开隐性开销

字符串是不可变的

Lua 字符串是内部化的不可变值：任何"修改"都会生成新字符串，短字符串还会进驻留池。理解这一点，两个高频坑就清晰了。

坑一：循环拼接。 s = s .. x 在循环里是 O(n²)——每轮都复制整个旧串。正确姿势是先收集后合并：

-- 差：1000 次全量复制
local s = ""
for _, name in ipairs(names) do s = s .. name .. "," end

-- 好：一次连接
local buf = {}
for _, name in ipairs(names) do buf[#buf + 1] = name end
local s = table.concat(buf, ",")

坑二：反复 tonumber/tostring 与格式化。 高频路径里 string.format("%d", x) 生成的临时串会加重 GC 负担，能复用就缓存格式化结果，尤其在 OnLoop 类触发器里。

table 的两层结构

Lua 的 table 同时是数组（连续部分）和哈希表（散列部分）。用 t[1]..t[n] 存数组时走连续内存，遍历最快；用字符串 key 或稀疏下标则走哈希，且稀疏数组会让 #t 长度语义变得不可靠——数组槽永远从 1 开始密集存放，别拿 table 当稀疏数组用。

建表时如果能预估容量，工程上推荐"构造器一次成型"：local t = {a, b, c} 比先 local t = {} 再逐个 t[i]= 少数次 rehash。虽然单次差异微小，万次循环里就是可测量级。

遍历方式的选择

ipairs 走数组部分、遇 nil 即停，最快；pairs 走哈希部分、顺序不保证，仅用于字典；已知长度时 for i=1,#t 与 ipairs 相当，但可以在倒序遍历、跳步遍历上更灵活。倒序删除元素务必倒着循环：

for i = #list, 1, -1 do
    if list[i].dead then table.remove(list, i) end
end

正着边遍历边 remove 会跳元素，这是排行榜、怪物列表刷新逻辑里最经典的隐性 bug。

一条排查路径

怀疑字符串/table 开销时，按顺序做三件事：collectgarbage("count") 前后对比定位内存增量；用 debug.sethook 做简易采样找热点函数；最后审查热点函数里的临时表与拼接。90% 的脚本性能问题都落在"循环拼接、循环建表、全局查找"这三件事上，改完它们，剩下的才值得动架构。

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

printusetime(play, on, off)

打印脚本总耗时(微秒)，字符串拼接与 table 扩容的代价必须用实测数据说话

printusetime(actor,1)

md5str(str)

MD5加密，字符串类工具函数里最常见的原生实现，性能基线参照

tbl2jsonex(str)

表格转换成字符串，隐性开销的重灾区，序列化前后都值得量一次

json2tbl(str, reslut)

字符串转换成表格，反序列化成本通常更高

【框架设计】宠物进阶：进化材料链与形态切换

【框架设计】坐骑系统：碎片合成与品质保底

【网络通信】动作与表情：社交广播的轻量协议

【性能调优】延迟结算：非紧急任务的队列消化

【安全加密】数据脱敏：日志与取证导出的隐私处理

【界面UI】BUFF 图标栏：增益排列与剩余时间