【性能调优】pairs 遍历中删除元素：next 的行为细节

实战应用：用在哪里

遍历一张表的同时删除元素是 Lua 的经典雷区：pairs 的迭代由 next 驱动，遍历中增删键的行为官方手册只有一句"允许置 nil 当前键，其余未定义"。行为没吃透就写清理逻辑，症状是时灵时不灵——这在测试里最难缠。

未定义行为的现场

---危险写法：遍历中删除非当前键
local buffs = { a = 1, b = 2, c = 3, d = 4 }
for k in pairs(buffs) do
    if k == "a" then
        buffs.c = nil   -- 未定义行为：可能跳过 c
    end
end

---安全写法：先收集后删除
local toDel = {}
for k in pairs(buffs) do
    if isExpired(k) then
        toDel[#toDel + 1] = k
    end
end
for _, k in ipairs(toDel) do
    buffs[k] = nil
end

pairs 迭代期间给非当前键置 nil，next 的返回顺序取决于哈希表的内部布局，删除可能让迭代器跳过紧邻的键——跳过的那个 buff 永远不被清理。安全写法的两段式成本：多一张待删表与一趟二次遍历，万级条目的表多花 2 毫秒，正确性的代价可以忽略。

高频清理的优化

---战斗 buff 的周期清理：倒序数组替代字典
setontimerex(49, 1)
function Buff.purge(actor)
    local list = actor.buffList
    for i = #list, 1, -1 do
        if list[i].expireAt < os.time() then
            table.remove(list, i)
        end
    end
end

清理是高频场景时，换数据结构比绕开坑更值：数组按倒序遍历删除，remove 的位移只影响尾部，跳元素的风险为零。字典到数组的改造让 buff 的遍历顺序稳定（先加先清），行为可测试。_expire 标记加惰性压实是第三种选择：遍历只打标，表膨胀到阈值后一次性重建，写多删少的场景最划算。

验证与监控

清理逻辑的覆盖率测试必须包含边界：表头删除、表尾删除、全删、空表；清理的残留检测——到期 buff 在表中的滞留时长监控，超过 3 秒即清理逻辑漏判。

踩坑记录

buff 清理曾经用危险的遍历中删除，压测通过上线后偶发的"buff 永久驻留"工单查了一周，根因是 next 跳键，两段式重写后绝迹。两段式的待删表曾经复用没清空，上一轮的键把新表的数据误删，每次使用前置空。倒序删除的数组曾经混入了非连续索引，# 取长度的结果截短了遍历，数组段与哈希段的混用规则进评审清单。

上线要点

遍历中修改容器的规则写进编码规范：字典两段式、数组倒序、大表惰性压实三选一。清理逻辑的单元测试进模板工程，新功能的清理代码有现成的测试骨架。数据结构的选型在容量评估时定：预估百级以下字典自由用，千级以上先想遍历与清理的路径。

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