【性能调优】数组空洞三坑：ipairs、# 号与删除操作的边界行为

实战应用：用在哪里

Lua 的数组本质是 table，一旦写入 t[5] = x 而 1~4 为空，数组就出现空洞。空洞会让 #t 的返回值变得不可预测（返回任何“边界”都是合法实现）、让 ipairs 提前停止、让 table.concat 与 unpack 输出缺失元素。背包、排行榜、怪物列表三类高频结构最容易踩坑。

三个坑的复现

local t = {}
t[1] = "a"; t[3] = "c"
print(#t)                 -- 可能输出 1 或 3，未定义行为
for i, v in ipairs(t) do  -- 只遍历到 "a"，"c" 被跳过
end
table.concat(t, ",")      -- 结果同样不确定

三个修复模式

模式一：table.remove 删除代替置 nil。 删除元素用 table.remove(t, i)（自动补位），而不是 t[i] = nil（制造空洞）。倒序遍历删除是标准姿势。模式二：计数器代替 #。 用 self.n 记录数量，增删时维护计数，读取 O(1) 且语义确定。模式三：填充哨兵。 固定长度数组用 false 填充空槽（false 在 ipairs 中会停止，改用数字 for + 显式判断）。

排查方法与基线

存量代码用三个静态特征扫描：t%[%d+%] = nil 的置空写法、ipairs 遍历的表是否有 remove 调用、# 取长度的表是否被直接下标赋值。命中点写一个回归测试覆盖边界（首、尾、空洞位），改动前先让测试复现问题。数组规范一旦统一（连续下标 + remove 删除 + 计数器），这类不确定性 bug 就从项目里消失了。CSV 配置解析器（数据存储篇）与战斗日志缓冲都按此规范实现，长期零事故。

数组规范的机器检查：用静态扫描脚本 grep 出三类可疑写法（数字下标直接置 nil、ipairs 遍历的表上出现 remove、# 取长度的表被稀疏赋值），扫描结果进构建报告。三个高危点各配一个回归测试用例：首元素删除、末元素删除、中间删除，用例覆盖后再改删除逻辑就有安全网。规范落地的前两周把扫描放进提交检查，团队习惯养成后可以降级为每周全量扫描。

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