C++ ECS架构是面向数据的设计模式，核心为实体（仅ID）、组件（纯POD数据）和系统（纯逻辑函数）三者分离；内存连续、缓存友好、支持并行，适用于高性能游戏开发。
C++ ECS 架构是一种面向数据的设计模式，核心是把“实体（Entity）”、“组件（Component）”和“系统（System）”三者分离，用数据驱动逻辑，而不是用继承驱动行为。它不是 C++ 专属，但在高性能游戏开发中特别适合——因为内存布局连续、缓存友好、天然支持并行处理。
Entity：只是 ID，不存数据也不带逻辑
实体本质是一个轻量级唯一标识符（比如 uint32_t 或 uint64_t），不继承、不含成员变量、不定义行为。它只起“关联作用”：告诉引擎“这个角色”由哪些组件组成。
- 避免传统 OOP 中的深继承树（如 Player ← Character ← GameObject ← Object）
- 运行时可动态增删组件，实现行为组合（例如给一个实体加 RenderComponent + PhysicsComponent 就变成可渲染+受物理影响的对象）
- 通常配合稀疏集合（Sparse Set）或实体池管理，保证分配/回收高效且局部性好
Component：纯数据容器，无函数、无虚表
组件是 POD（Plain Old Data）结构体，只包含字段，比如 Position { float x, y, z; }、Velocity { float dx, dy, dz; }。它不包含任何方法、不继承、不持有指针（或尽量避免）。
- 好处是能批量连续存储（如所有 Position 放在一块内存里），遍历快、CPU 缓存命中率高
- 建议用 SOA（Structure of Arrays）或 AoS+对齐优化，尤其在需要 SIMD 处理时（如同时更新 1000 个 Velocity）
- 避免在组件里放 std::string、std::vector 等堆分配类型；若必须，用索引或句柄间接引用
System：按需处理匹配组件的实体，专注逻辑
系统是纯函数式逻辑单元，例如 PhysicsSystem 遍历所有带 Position 和 Velocity 的实体，更新位置；RenderSystem 拿到所有带 Transform 和 Mesh 的实体，提交绘制命令。
- 系统之间无依赖（理想情况下），靠数据流解耦；执行顺序由调度器控制（如先 Physics → 后 Animation → 再 Render）
- 常见实现方式：编译期反射（如使用宏或 C++20 Concepts）自动发现组件依赖；或运行时注册查询签名（如 bitset 表示所需组件类型）
- 天然适合多线程：多个系统可并行跑（只要不写同一组组件），或单个系统内对组件数组做分块并行处理
实际落地要点（C++ 特色）
纯理论 ECS 很简洁，但 C++ 实现要考虑效率与可控性：
- 用 archetype 或 chunked storage（如 EnTT 的 “group” 或 flecs 的 “type-based storage”）提升遍历性能，避免指针跳转
- 组件访问通过 view 或 query（如 auto view
= registry.view()），底层返回连续指针，直接 for-range 即可 - 事件通信不走 Observer 模式，改用 event queue（如 CommandBuffer 或 ring buffer）或 tag component（如 Added
）触发响应 - 不排斥少量面向对象：工具层、编辑器交互、脚本绑定仍可用 class 封装；ECS 主要用于运行时高频逻辑和数据密集部分
= registry.view
