遍历一张表的两个函数:ipairs 按数组序走、pairs 按哈希序乱走。选错的后果不只是性能——顺序敏感的逻辑(发奖的次序、菜单的编号、回放的步骤)用 pairs 会乱套,语义的选择是正确性问题。
---发奖的次序:ipairs 保证按配置顺序发
local REWARDS = { "金币袋", "强化石", "签到礼包" }
function Reward.sendAll(actor)
local player = class(actor)
if not player then return end
for i, item in ipairs(REWARDS) do
giveitem(actor, item, 1)
sendmsg(actor, 1, i .. ". 已发放 " .. item)
end
end
---背包的扫描:pairs 覆盖全部键
function Bag.countItems(actor)
local n = 0
for slot, item in pairs(Bag.of(actor)) do
if item then n = n + 1 end
end
return n
end
选择的判断法一句话:需要顺序用 ipairs,只需要覆盖用 pairs。发奖的次序是承诺(第一格金币袋、第二格强化石),ipairs 的数组序兑现它;背包的盘点不在乎格子的顺序,pairs 的全覆盖不漏一格。混用的两类事故:该用 ipairs 的地方用 pairs,发奖的顺序乱、菜单的编号错、回放的步骤跳;该用 pairs 的地方用 ipairs,带空洞或字符串键的表被提前截断。
---ipairs 遇到 nil 即停
local configs = { [1] = "A", [2] = nil, [3] = "C" }
for i, v in ipairs(configs) do
print(i, v) -- 只打印 1:A,3:C 被跳过
end
---安全的计数遍历:先取长度再走
local n = table.maxn(configs)
for i = 1, n do
local v = configs[i]
if v then print(i, v) end
end
---混装的表用 pairs 兜底
local mixed = { "金创药", tag = "药店", [10] = "魔法药" }
for k, v in pairs(mixed) do
print(k, v) -- 全部键值都会到达
end
ipairs 的铁律是遇到第一个 nil 即停:配置表中间挖了洞,洞后的配置集体消失——配置装载时的完整性校验(无空洞断言)是上游的防线,遍历侧的防御是先 table.maxn 取上界再逐个判空。混装的表(数组段加哈希段)只有 pairs 能全覆盖。性能的注脚:ipairs 比 pairs 略快(数组段的迭代更直接),但选择的第一依据是语义,性能是顺带的。
遍历的单元测试带三类表:纯数组、含空洞、混装键,断言遍历的覆盖数与预期的键集合一致;配置装载的空洞检测,带洞的表在装载时报出行号。
菜单的编号曾经用 pairs 生成,同一菜单两次打开的选项顺序不同,玩家的肌肉记忆错乱,编号改为 ipairs 顺序生成。任务步骤的回放曾经被空洞截断,中间步骤的跳失让流程状态错乱,步骤表的下标连续性进装载校验。pairs 遍历中修改键的历史坑(跳键)与本次的语义选择共同写进团队的遍历规范。
遍历的规范三句话进编码手册:顺序敏感 ipairs、全覆盖 pairs、遍历中不增删。配置表的装载校验带空洞断言,洞在上游被拦。代码评审对遍历的选择提问一句:这里需要顺序吗?
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 付费玩家不是一个人群,是四层结构各异的群体:白嫖党、月卡党、中产党、大R党。大R(月消费 3000 元宝以上)贡献…
设计初衷 传送是全服使用频次最高的功能(人均每日 6.2 次),也是最没有存在感的收费点——玩家对它的态度是"顺手付了"。定…
底层原理 弱值表(__mode = "v",值被弱引用)之外还有弱键表(__mode = "k",键被弱引用):键不被表挽留…
设计初衷 战法道互相克制是传奇的魂:战士近身爆发(烈火剑法)、法师远程群攻、道士续航消耗,三角循环转起来才有博弈。胜率失衡的…
业务场景 基础仓库 40 格,裁决之杖收藏家们叫苦不迭。扩容方案:每页 10 格、最多扩 4 页到 80 格,第 1 页 1…
底层原理 math.random 不承诺完美均匀,而爆率、抽奖、抽签全部建立在"均匀"假设上。均匀性是可检验的:n 个桶各掷…