【框架设计】ECS 与有限状态机组合：500 个战斗体的 Lua 实现

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

实战应用：用在哪里

大规模同屏战斗（百人攻城、几百召唤物）里，纯 OOP 方案的对象开销与纯 ECS 方案的行为表达各有短板。本文给出两者组合的实现要点：ECS 管数据与批量系统，FSM 管单个实体的行为阶段，实测 500 个战斗体在 LuaJIT 下帧耗时稳定在 1.8ms 以内。

组合结构：组件存数据，FSM 存阶段

每个战斗体是一个实体 id，组件包括 Position、Combat（攻防血量）、FSMState。FSM 不再每个实体一份完整状态表，而是把状态机模板全局共享一份，实体只存"当前状态名 + 进入时间"：

-- 全局共享的战斗状态模板
local CombatFSM = {
    idle   = { next = "moving", timeout = 2 },
    moving = { next = "attacking" },
    attacking = { cooldown = 0.8 },
}

-- 移动系统按状态分发，只扫 movable 组件
for id, mv in pairs(World.movable) do
    local st = World.fsm[id]
    local def = CombatFSM[st.name]
    -- 按阶段推进，超时自动切换
end

状态模板共享让 500 个实体的行为定义只有一份，新增状态改一处全量生效。

三个性能要点

组件表按访问模式分列。 移动系统只读 movable 与 pos，两张表连续遍历；战斗结算每 0.5 秒跑一批，与逐帧系统分离。销毁走统一入口。 World.destroy(id) 同步清空全部组件表，漏清的幽灵实体会让每帧遍历越来越长——某项目 3 天后帧耗时翻倍，定位结果就是销毁函数漏了 fsm 表。LuaJIT 白名单。 系统循环里避开 pairs、字符串拼接与 FFI 混用，用 -jv 确认核心循环 trace 编译成功，编译与未编译的差距在批量场景下是 4 倍起步。

测试与验收

行为正确性用 busted 做无头测试（注入假时钟驱动 1000 帧，断言状态序列与坐标区间）；性能验收以 500 实体 10 分钟压测为准：帧耗时 p95 低于 2.5ms、实体数量曲线无单调增长（无泄漏）。组合架构跑通后，往里加新战斗玩法（新组件+新系统）不再触碰存量代码，这是它对团队最大的价值。