为什么「谁在用」比「它有多强」更该先看

去年秋天一个 game jam 的群聊里，有个做模拟经营的小哥凌晨两点发了条消息：「我把三个月的工作量推了，用 Flecs 重写，两周出了能玩的版本。」底下有人问他后悔吗，他回了句：「后悔没早推。」

这故事我记住了，不是因为它励志，是因为它太典型了——Flecs 的案例几乎都长这样：小团队、一个人、一个「本来要写死的系统突然活了」的瞬间。你翻它的官方 Showcase，看不到什么大厂 logo 墙，看到的多是这种带点土味的项目。

所以这篇不打算给你灌「ECS 多强」的鸡汤。我想干的事更朴素：把这批真实项目摊开，看它们的用户画像、选型动机、用前用后的数字，然后回答一个具体问题——你这种项目，走这条路到底能不能活。

上一篇我们聊了从 OOP 到数据驱动的认知重建，那是心法。这篇是「见过谁练成了」。下一篇再去挖 Archetype 的内存模型，那是内功。顺序别乱：先知道谁在用、为什么用、用完什么感觉，再去啃底层，不然你会在内存对齐的细节里把热情耗尽，然后得出「ECS 是骗局」的结论——我见过不止一个人这么干。

第 1 层：先画用户画像——用 Flecs 的到底是哪群人

先把话说死：Flecs 的用户盘子不大，但非常集中。我翻了一圈公开的 Showcase、作者访谈、社区讨论，能归纳出三类人，几乎没有第四类。

你注意 A 类占比最高，这不是巧合。Flecs 的 C 语言基因决定了它「没有引擎包袱」——它不绑渲染、不绑物理、不绑编辑器，一个人可以把它塞进任何自己拼的技术栈里。反过来，这也筛掉了一大批想要「开箱即用」的人，这个我们第二层细说。

深度案例一：官方仓库里的城市模拟演示。这个 demo 我看过很多次，社区里也常有人拿它跑性能基准，但很少有人认真聊它「好玩在哪」。它的结构大概是这样的：每栋建筑是一个实体，带位置、类型、容量；每个市民是一个实体，身上挂着「住在哪」「在哪上班」两条关系，外加饥饿、疲劳、娱乐几个需求值；道路本身也是一堆带连接关系的实体。系统是分层的——每天做一次的人生决策（找工作、搬家）跑在低频层，移动和需求变化跑在高频层。

玩家在这个 demo 里没有操控权，你是个旁观者。你把面包店拆了，三天后城市某个区开始饿死人，这个因果链你能在实体列表里一路追下去：谁在挨饿、他原本该去哪、那条路为什么没走通。这就是我认为它最有价值的地方——因果可见。传统 OOP 写模拟经营，市民和建筑互相持有引用，出问题的时候你在对象图里绕圈，最后只能加日志猜。ECS 里你看到的是数据，谁缺什么组件一目了然。

参数上，这类演示的量级大概是：市民 2000 到 20000 个（超过 5 万就要考虑给远处市民降频了），需求衰减速率按游戏内时间算，饥饿每分钟掉 1 点、疲劳每分钟掉 0.5 点这个区间比较好调，市民决策每 2 到 5 秒跑一次，移动每帧更新。一个市民平均挂 3 到 6 条关系，超过 10 条你就该怀疑是不是把「属性」错当成「关系」了。

收益和代价都得说。收益是加一种新建筑，等于加一个组件加一个查询，老代码一行不动；代价是调参地狱——需求曲线稍微陡一点，全城集体饿死；平一点，城市变成一潭死水。这其实不是技术问题，是策划问题，但 ECS 会把它暴露得特别快：你昨天随手写的那个「娱乐需求每秒衰减 2 点」，今天就会让你看见三千个市民集体抑郁。我说句实话，第一次看到这种场面我是有点慌的，因为它太直观了，直观到你没法甩锅给程序。

第 2 层：选型动机拆解——他们为什么没选 EnTT 也没自研

「为什么用 Flecs」这个问题的答案，比「Flecs 有什么特性」有用一百倍。我把社区里反复出现的动机归了归类，大致是这几条，权重从高到低：

看到没，性能排在最后。这跟大部分人的直觉相反——大家以为选 ECS 是为了快，实际上小团队选它，八成是为了「结构能撑住」。

深度案例二：官方仓库的 Roguelike 演示。这个案例特别适合拿来讲动机，因为回合制游戏和 ECS 是天生一对，但理由跟你想的不一样。

里面大概是这么运转的：格子地图的每格是一个实体（或者一片格子打包成一个实体，两种做法都有人用），怪物是实体，身上挂着位置、生命、攻击、AI 标签；怪物模板做成预制体，生成的时候只覆盖几个字段，比如「这只哥布林比模板多 5 点血」。视野靠查询范围内的实体解决，谁在半径内谁就被点亮。回合制的关键是——玩家按一次方向键，所有怪物「同时」想一步，其实内部是按顺序算的，只是快到你感觉是同步的。

玩家体验上，这种结构给的东西是「世界有呼吸感」。你站在原地不动，怪物会自己巡逻、会发现你、会追；你退一步，它们的追击路径跟着变。这种体验在 OOP 里也能做，但一旦你想加「会隐身的怪」「会召唤的怪」「被点燃会乱跑的怪」，继承树就开始打结了。ECS 里加一种怪，就是加一个组件组合加一条行为规则，互不干扰。

参数建议：地图 60×40 到 120×80 格，怪物数量 30 到 200 只比较舒服，视野半径 6 到 10 格。这里有个反直觉的点——回合制下 ECS 的性能优势基本用不满，因为实体太少，你根本跑不到瓶颈。你买的是结构清晰，不是跑分。这点想不明白的人，就会觉得「用了 ECS 也没变快啊，是不是智商税」，然后回去写继承。

再说反例，为什么有人三天就走了。我见过三个，理由高度一致：他们以为 Flecs 是引擎。Flecs 不管渲染、不管物理、不管 UI、不管音频、不管资源加载，连个像样的编辑器都没有。你要做游戏，得自己把这一圈拼起来。这对于「我就想做个游戏」的人是灾难，对于「我想搭自己的技术栈」的人是天堂。同一件事，两种人，两种命运。

第 3 层：用前用后的数字——哪些能信，哪些是营销口径

聊数字之前先打个预防针：这个圈子里的性能对比，水分比你想的大。原因很简单——「迁移前」的那套代码往往写得很烂，拿烂代码当基线，什么框架都能提升十倍。所以我下面给的数字，会标注口径，你自己打折。

先看一张典型的小项目迁移表。这类项目大概是同屏几千个实体、七八个系统、单人开发半年的量级，数字来自社区自测和我自己折腾过的小实验，不是官方基准：

最后一行不是玩笑。ECS 不会让你不写 bug，它只是把 bug 换了个形态——从「对象不存在」变成「组件缺失」。你查询的时候忘了排除某个标签，就会看见一堆不该出现的实体在跑，调试方式完全不同。这也是为什么上一篇我反复强调思维转型，工具换了脑子不换，照样翻车。

跨类辅助案例：Tiny Glade。两个人做的建造小品，用的是 Bevy 那套 Rust 生态的 ECS，不是 Flecs，但机制逻辑可以借来对照。玩家在里面随手画一条线，墙就长出来了，还能拖拽变形，实时看到砖块堆叠。这里面的关键不是「能处理多少实体」，而是局部更新——你动了哪一块，系统只重算被影响的那部分，剩下的纹丝不动。玩家感知到的是「手感跟手」，背后是一整套「只碰该碰的」的数据组织。

这跟 Flecs 那些模拟案例是同一个道理：ECS 真正的价值不在「跑分高」，在「改一点东西的成本低」。Tiny Glade 的代价也很典型——他们得自己搞定几何生成、网格合并、渲染管线，ECS 只负责把数据理清楚。你看，绕了一圈又回到那句话：它不管渲染。

跨类对照案例：Unity DOTS 的 MegaCity 演示。这是另一个极端，官方拿它展示几十万实体同屏的规模天花板。它的意义是告诉你「上限在哪」，但代价是概念多、构建慢、学习曲线陡。Flecs 的案例很少冲到那个量级，不是因为做不到，是因为用 Flecs 的人大多不需要——一个两人小队做模拟经营，同屏两万市民已经足够让玩家喊「这城市活了」，再往上加，玩家感知不到，你的调试成本倒是翻倍。

所以看案例数字的时候，我建议你只信两栏：「新增内容耗时」和「改需求耗时」。这两栏最贴近独立开发的真实痛点，也最不容易注水。帧时间那栏，除非你能复现别人的场景，否则看看就好。

第 4 层：成功案例的共性——赢的不是技术，是内容产能

把上面这些案例摆一起看，你会发现一个有点扫兴的结论：没人是因为「用了 ECS」而成功的。他们成功，是因为 ECS 帮他们把「从想法到可玩」的时间压短了。独立游戏最缺的从来不是性能，是时间。

我把共性归了四条，每一条都能落到具体体验上。

第一条，数据即内容。一种塔、一种怪、一种建筑，在 ECS 里就是一个组件组合。策划想加「减速塔」，程序加一个减速组件，在移动系统里查一下谁身上有这个组件，速度乘个系数，完事。不用改继承树，不用怕漏改某个子类。玩家这边感受到的是——版本更新快，上个礼拜提的建议这个礼拜就进游戏了。这个循环一转起来，社区口碑就起来了。

第二条，迭代速度。改一个组件，所有引用它的系统跟着变，你不用去十个文件里同步修改。这条听起来很工程师，实际影响的是玩法实验的频率。你今天想试「让市民晚上才回家」，改一个时间判断，跑一遍，不行明天再改。这种「一天试三个想法」的节奏，是 OOP 结构撑不住的。

第三条，调试可见性。运行时把实体列表一拉，谁有什么组件、谁缺什么、谁和谁有关系，全是明面上的。玩家反馈「我的工人不干活了」，你三分钟能定位到是「工作地点关系断了」还是「疲劳值卡在阈值上」。这省下来的时间，最后都会变成内容。

第四条，模块复用。一个世界装多个模块，战斗模块、建造模块、AI 模块互不干扰。你上一个项目写的 AI 模块，下一个项目直接搬过来。对独狼开发者来说，这是复利。

拿塔防串一遍你就懂了。传统写法里，塔是个基类，箭塔、炮塔、冰塔继承下来，每种塔有自己的攻击逻辑。你想加个「攻击时给敌人上减速」，得在基类或者好几个子类里加钩子。ECS 写法里，塔就是一个「位置 + 攻击范围 + 伤害 + 冷却」的组件组合，减速是另一个组件，攻击系统只管「谁有攻击组件就按冷却打，打中了就看看对方身上有没有减速组件」。加一种塔是加数据，不是改代码。这个差别，在你做到第十种塔的时候会救命。

参数化工具：一张选型自检表 + 一张收益预估表

光看案例不过瘾，你得知道自己的项目落在哪个格子里。下面两张表可以直接拿去对着填。

表一：要不要考虑 Flecs 的自检表

表二：迁移收益预估表（经验区间，非承诺）

两个表都有个隐藏前提：你的瓶颈得在逻辑层，不在渲染层。如果你的游戏卡在绘制上，换成 Flecs 一点用没有，帧时间该多少还是多少。我见过有人兴冲冲重构完，发现帧率纹丝不动，最后查到是粒子特效开太多。那种心情，我懂。

双路径阅读：初级速览 / 进阶深入

初级路径（你刚开始做第一个项目，或者刚决定要不要换）：你只需要记住三句话。第一，Flecs 的案例集中在模拟、Roguelike、建造这几类，共同点是「同类实体多、需要组合、需要反复加内容」，如果你的游戏符合这个画像，值得试。第二，它不管渲染物理 UI，你得自己拼技术栈，这是一道硬门槛，跨不过去就别硬跨。第三，别看性能数字，看「新增一种敌人要多久」这个指标，那才是你天天要面对的事。

具体动作上，我建议你干一件事：拿你现有项目里最乱的那个系统，用 Flecs 重写一遍，只写这一个。跑通了，你就有感觉了；跑不通，你也能在两周内知道原因，不至于把半年搭进去。这比看一百篇案例都管用。

进阶路径（你已经有两个项目经验，在评估长期架构）：你要看的不是「谁用了」，是「谁用了之后付出了什么」。重点扒三样东西：一是他们的组件怎么划分的，粗了会查询爆炸，细了会碎片化；二是他们的系统怎么分层的，哪些跑每帧、哪些跑每秒、哪些跑每分钟；三是他们怎么处理关系的，什么时候用关系、什么时候老老实实存个 ID。这三样决定了项目跑到十万行还能不能维护。

还有一个进阶视角：留意案例里「没说的部分」。没人会写博客说自己重构失败，但你从项目更新日志的节奏、从社区提问的密度，能看出一些端倪。比如某个项目连续三个月在 issue 里问碎片化问题，那它的组件划分八成出了毛病——这种信息比成功学有用得多。

争议与常见坑：案例盘点的三个陷阱

还有一个争议值得摆到台面上：Flecs 的公开案例确实不多。这不代表它不好，代表它还在生态早期，而且它天生筛掉了「想要开箱即用」的那批人——而那批人恰恰是最爱写教程、最爱发视频的。你看到的案例密度，和框架的实际成熟度，是两件不同的事。这话我不是替它洗地，是真的见过太多人拿「案例少」当「不行」的证据，然后选了个案例多但架构烂的框架，两年后哭着重构。

最后一个坑，也是最常见的：照搬别人的架构。别人的组件怎么划分，是基于他的玩法。你的玩法不一样，照抄就是灾难。有个朋友做卡牌 RPG，抄了一个模拟经营项目的组件结构，结果卡牌那一堆状态互相打架，最后全部推翻重来。组件划分是玩法问题，不是技术问题，这话我说过很多次，还是有人不信。

FAQ

Q1：Flecs 有没有真正的商业大作案例？

坦白说，公开可见的重量级商业案例很少，官方 Showcase 里以中小项目和个人作品为主。这不是缺陷，是阶段——它不像 Unity 那样有十年商业积累。你要评估的是「这个框架的能力够不够我用到发售」，而不是「有没有大厂背书」。一个两人小队做模拟经营，用它跑到上线完全没问题，这点我能打包票。

Q2：单人开发用 Flecs 是不是杀鸡用牛刀？

要看你做什么鸡。做线性剧情向的小品，确实是牛刀，用现成引擎省事得多。做模拟、Roguelike、建造这类「同类实体多、需要反复加内容」的游戏，它反而是省力的——因为你省下的不是性能，是每次改需求时那种「又要动五个文件」的心累。

Q3：官方 demo 能直接当参考架构吗？

能当字典，不能当剧本。看它怎么组织数据、怎么分层系统，学思路；别照抄组件划分，那是为演示服务的，不是为你的玩法服务的。我建议你把 demo 跑起来，然后故意改坏它——删一个组件、改一条关系，看世界怎么崩。这个过程比读十遍源码都长记性。

Q4：案例里的性能提升数字能信吗？

打折看。折扣力度取决于对方原来的代码有多烂。你唯一该信的是「新增内容耗时」这类工程指标，还有「改需求后回归测试的工作量」。帧时间那栏，除非你能复现对方的场景，否则就当故事听。

Q5：我的游戏是剧情向、线性关卡，需要看这些案例吗？

可以看，但别急着抄。这类游戏的核心是叙事节奏和演出，实体数量少，ECS 的结构收益体现不出来。你真正能从这些案例里借的，是「数据即内容」这个思路——把对话、事件、关卡配置都当成数据来管，这个习惯跟用不用 ECS 没关系，但用上了会让你后期加内容轻松很多。

最后留个问题给你：如果明天你的项目要加一种全新的敌人，需要动几个文件？这个数字，比任何框架对比表都更能说明你现在的架构到底行不行。