mark!!
更新到最新版本就可以解决了，新版本解决这个问题了
谢谢大佬1小时搞定
mark一下！！
ECS框架更新v2.1.45
- 新增World概念（支持多个World管理多个Scene)
文档： ecs-framework/docs/scene-management-guide.md at master · esengine/ecs-framework
单场景迁移指南（不影响现有单场景功能仍可使用）
// 原始单Scene代码
const scene = new Scene();
Core.setScene(scene);
// 迁移到World模式（可选）
Core.enableWorldManager();
const world = Core.getWorldManager().createWorld('MainWorld');
const scene = world.createScene('main', new Scene());
world.start();
world.setSceneActive('main', true);
注意：原scene属性set索引器已移除，请更改为setScene方法避免上下文丢失问题
- 优化内部索引机制（移除bitmap/hash/sorted等索引类型更改为SparseSet索引减少切换索引开销）
- SOA存储器新增多个安全方法 getTypedFieldArray/getEntityIndex/getEntityIdByIndex
1赞
写了大半年的ecs多人同步割草游戏，前后端用同一套代码，尝试过状态同步、状态+帧同步、纯帧同步。
ecs优点就是：
每种方案都可以通过不同系统之间的组合方向实现功能
策划想怎么改都行，功能改动灵活不受代码复杂度的影响，想改功能就改改系统和组件组合就行，代码逻辑松散解耦
用ecs旧项目改成新项目很快，改改组合
缺点:
代码逻辑松散解耦，实现一个功能要分几个系统和文件，导致新人比较难上手你的代码，需要新人先理解框架大致整体流程再看细节
由于功能要分几个系统和文件，调试起来麻烦，比较难跟踪同个实例，这需要另外写调试工具
由于系统组一帧内只能按顺序执行，在有些情况下需要递归处理的逻辑不好处理，比如 角色攻击 buff效果后又产生buff， buff后面的系统产生的buff可能要等下一帧再执行等…解决类似问题没有传统写法那么轻松
某些情况下性能没传统写法好，很多时候要用传统写法+ecs写法解决类似问题
对比cocos那种功能组件写法，优点在于
实体和组件写好后基本不用动，改业务逻辑大部分只改系统那部分文件
比如前后端共用一个实体和组件(属性)，前后端有各自系统组合(逻辑)实现具体功能
对于没用过ECS项目人来说，上手是有点难得
3赞
是的，很赞同你的说法，虽然说起来ecs就是三个部分的组成，entity/component/system，但是实际上内部里实现比如querysystem, archetypesystem，各种storage其实用户虽然表面上用不到但是内部框架要做的事情还是有很多的，并不是实际上看到的那么简单。
你说的缺点我也在积极的解决，比如调试困难所以我才想推出调试插件并且你说的buff级联问题，我在新版本里也准备推出 命令缓冲模式 要到下一个大版本才推出，将需要递归处理的操作延迟到当前帧结束后统一处理，还有其他的新特性，确定性的系统排序，还有比如帧同步里常用的一些可复现随机数还有包括全量快照和增量快照，还有其他类似回放的功能等等，不过工作量都比较大，都需要循序渐进的推动。
对于新人上手难这个确实是ECS的通病，只能写一些标准的系统模板和最佳实践的文档让他们遵循统一的开发模式。
实体间的关系是父子还是组合
目前提供的是父子，但是不推荐使用，默认是关闭的，需要再初始化的时候手动打开这个，推荐自己实现实体关系