ECS 中的概念缺失
这篇讲的是作者团队在实际项目中对 ECS（实体-组件-系统）架构的一次重要反思与演进。他们指出，传统 ECS 过分强调 Component 和 System 这两个底层概念，导致在搭建复杂业务（如现代渲染管线）时，开发者需要手动组合数十个组件和系统，流程繁琐且极易出错。 为此，他们引入了两个更高层的抽象概念来解决问题。第一是 **Policy**，它将实现某个特定功能（如“可渲染物件”）所需的所有 Component 及其初始化流程封装起来。开发者创建 Entity 时只需描述其具备哪些 Policy，而无需关心底层数据构成。第二是 **Pipeline**，它用一棵树状结构来定义 System 的执行顺序，开发者可以将 System 注册到流水线的特定节点上。 通过这套设计，他们实现了将框架的复杂性封装起来，让业务层开发者只需关注 Policy 列表、Pipeline 配置和初始数据，无需直接处理 ECS 的底层细节。这既保持了 ECS 解耦与数据驱动的核心优势，又大幅降低了实际使用的门槛，确保框架能真正服务于业务开发效率。