【框架设计】ECS 架构：实体组件系统在 Lua 里的轻量实现

完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn

实战应用：用在哪里

怪物、宠物、机关、投掷物越加越多，每个都写一份"移动+战斗+掉落"的类，重复代码膨胀难改。ECS（实体-组件-系统）把"是什么"拆成组件（Position、Health、Movable），"做什么"拆成系统（移动系统、战斗系统），实体只是一串组件的集合。新增飞行怪物 = 挂一个 Flying 组件，不改任何系统代码。

Lua 里的轻量 ECS

实体用整数 id，组件存两张表，系统是纯函数：

local World = { nextId = 0, pos = {}, hp = {}, movable = {} }

function World.spawn(x, y, hp)
    World.nextId = World.nextId + 1
    local id = World.nextId
    World.pos[id] = { x = x, y = y }
    World.hp[id] = { cur = hp, max = hp }
    World.movable[id] = { speed = 60 }
    return id
end

-- 移动系统：只遍历 movable 表
function World.moveSystem(dt)
    for id, m in pairs(World.movable) do
        local p = World.pos[id]
        p.x = p.x + m.speed * dt
    end
end

组件表分开放的好处：移动系统只扫 movable 表，遍历规模与"会动的实体数"成正比，而不是全实体数。

与 OOP 类系统的取舍

元表类系统（前篇方案）适合"对象数量少、行为复杂"的 Boss；ECS 适合"数量大、行为同质"的群体（几百只小怪、成片箭矢）。实测 500 个移动实体：元表方案每帧 3.1ms，ECS 连续数组方案 1.2ms，差距来自 table 跳转与元表查找的减少。

系统执行顺序与销毁

系统按固定顺序驱动：输入 → AI → 移动 → 碰撞 → 战斗结算 → 渲染同步。实体销毁时把三张组件表的对应 id 全部置 nil，漏一张就是经典的幽灵实体 bug——封装 World.destroy(id) 统一清理，业务禁止直接置 nil。战斗结算类系统的内部逻辑保持纯函数（读组件、写组件、无全局副作用），配合 busted 可以脱离引擎直接测数值流转。

实体 id 建议带上代际位（高 8 位存代数，低 24 位存序号），销毁后代数加一，防止滞后引用拿到已被复用的实体。遍历用 pairs 还是数字 for 取决于 id 是否连续，连续 id 用数字 for 更快，这点在批量场景差异会被放大。nn## 测试与验收清单nnECS 的验收按三个断言走：组件表数量一致（pos 表与 hp 表的键集合必须相同）、系统执行顺序符合配置、销毁后三张表全部无残留键。用 busted 写一个 500 实体的压力测试，跑 1000 帧后断言存活实体数与销毁日志一致。验收通过再接入引擎，出问题的排查范围就限定在新加的系统里。`n