【性能调优】字符串拼接的四种写法性能对比

实战应用：用在哪里

拼字符串是 Lua 的日常：日志格式化、聊天组装、公告模板，写法至少四种——连点拼接、table.concat、string.format、循环累加。四种写法的性能差出数量级，选错场合的代价在热路径上被放大。

四种写法的实测

---基准：1 万段碎片拼成一个串
local parts = {}
for i = 1, 10000 do parts[i] = "段" .. i end

local t0 = os.clock()
local s1 = ""
for i = 1, 10000 do s1 = s1 .. parts[i] end    -- 连点累加
local t1 = os.clock()

local t2 = os.clock()
local s2 = table.concat(parts)                  -- concat 一次成型
local t3 = os.clock()

local t4 = os.clock()
local s3 = string.format("%s%s%s", parts[1], parts[2], parts[3])
local t5 = os.clock()

print(string.format("累加 %.4f  concat %.4f  format %.4f",
    t1 - t0, t3 - t2, t5 - t4))

万段碎片的实测：连点累加 120 毫秒，table.concat 0.6 毫秒——两百倍的差距来自中间串的反复创建，每次 .. 都把已拼内容整份拷贝，二次方的时间复杂度。concat 先算总长一次性分配，线性复杂度。format 居中，模板类的小拼接（三五个占位）可读性最好，性能与 concat 同档。

场景的选择

---日志行的拼接：碎片多走 concat
function Log.line(tag, kvs)
    local buf = { tag }
    for i = 1, #kvs, 2 do
        buf[#buf + 1] = kvs[i] .. "=" .. tostring(kvs[i + 1])
    end
    return table.concat(buf, " ")
end

---公告模板：占位少走 format
function Notice.render(tpl, name, item)
    return string.format(tpl, name, item)
end

场景的选择规则三条：碎片超过五段用 concat 收集后一次成型；模板化的格式（公告、飘字、邮件标题）用 format 保持可读；两三段的简单场景连点直拼，过度工程不如直白。热路径的红线：攻城的伤害日志曾经用累加写法，千人同屏时日志拼接吃掉 15% 的 CPU，改 concat 后降到 2%——写法的选型在热路径上是数值问题不是风格问题。

验证与监控

基准脚本进版本库随引擎升级重跑，写法的性能画像有历史曲线；热路径的 CPU 火焰图周检，字符串函数的占比超过 5% 即回头查拼接写法。

踩坑记录

累加写法曾经藏在日志库深处，调用方以为日志很便宜，根因排查半天找到累加的循环。concat 的分隔符曾经默认空串，想要空格的日志挤成一团，分隔符显式传参。format 的占位符与参数个数曾经不匹配，多余的参数被静默忽略，格式串与参数的配对进单测。

上线要点

拼接写法的选择表进编码规范，附基准数据让规范有据可依。日志库内部强制 concat，调用方无感知。性能回归的基准场景覆盖日志、聊天、公告三类拼接大户。

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