【性能调优】局部变量缓存：全局表查找的热点消除

实战应用：用在哪里

Lua 读一个全局变量是一次哈希查找，读一个局部变量是一次栈上索引——差距在热路径上被放大：火墙的每秒结算、攻城的每帧伤害，函数与常量反复走全局表查找。局部变量缓存把热点查找搬到栈上，是零风险的老牌优化。

查找的开销实测

---全局查找与局部缓存的基准对比
local COUNT = 1000000
local floor = math.floor      -- 局部缓存引擎全局表的函数
local cfg = FIREWALL_DEF      -- 局部缓存配置表引用

local t0 = os.clock()
for i = 1, COUNT do
    local v = math.floor(i * 0.4)   -- 每次两跳全局表
end
local t1 = os.clock()
for i = 1, COUNT do
    local v = floor(i * 0.4)        -- 栈上直接索引
end
local t2 = os.clock()
print("global", t1 - t0, "local", t2 - t1)

百万次循环的实测：走全局表的版本 0.9 秒，局部缓存的版本 0.31 秒，快出近两倍。循环体越大、查找次数越多，收益越大。字符串常量同样受益：反复用的 "火墙术" 这类键名提升为局部常量。

热路径的改造

---个人定时器结算的热路径改造
setontimer(actor, 8, 1, 20)

local floor = math.floor
local getvar = getplayvar
local harm = rangeharm

function FireWall.onTick(actor)
    local fx = getvar(actor, 2, FW_KEY_X)
    local fy = getvar(actor, 2, FW_KEY_Y)
    local magic = actor:GetMagic()
    harm(actor, fx, fy, 2, floor(magic * 0.4), 0, nil, nil, nil, 12)
end

改造把 rangeharm、getplayvar、math.floor 提为文件级局部引用，结算函数体内不再出现点号链式查找。火墙每秒结算一次是低频场景，收益有限；真正的收益在攻城脚本：千人同屏时每帧调用数千次的伤害公式，同样的改造让单帧结算耗时下降 28%。改造的纪律：只处理每帧调用超百次的热点，冷路径为了两个局部声明牺牲可读性得不偿失。

验证与监控

改造前后的基准脚本对比必须同数据集同机器，收益低于 10% 的改造不合并；火焰图周对比确认没有新的查找热点冒头。

踩坑记录

局部缓存曾经缓存了函数表的引用而引擎热重载替换了表内容，缓存指向旧表行为诡异，热重载的钩子里同步刷新局部引用。文件顶部的局部声明超过 200 个后可读性崩坏，收敛为只缓存三类：数学函数、高频引擎接口、配置表根引用。循环内的局部声明位置曾经放在循环外过远，维护者误以为是全局，热点函数的声明贴着函数头放置。

上线要点

热点函数清单与性能基线联动，基线恶化的接口自动进改造候选。代码评审的检查项：热路径函数体内禁止三段以上的点号链式查找。基准脚本进版本库，每台构建机跑同一基准，跨机器的数据才有可比性。

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