Archetype 通过将相同组件集合的实体聚合成连续内存块并按列存储组件数据，使CPU缓存预取高效，遍历时避免随机访问；Sparse Set用dense/sparse双数组实现O(1)实体ID查找。

Archetype 为什么能提升遍历性能

Archetype 的核心是把拥有相同组件集合的实体聚合成连续内存块，避免遍历时跳来跳去。比如 Position + Velocity 的实体全挤在一块数组里，CPU 缓存预取就能一次拉进多个对象，而不是在堆上随机找。

关键点在于：每个 Archetype 对应一个独立的 std::vector（或自定义连续容器），里面只存该组合的组件数据（通常按列存储，如所有 Position.x 连续、所有 Position.y 连续），而非实体对象本身。

• 新增实体时，先查是否有匹配 Archetype；没有就新建，有就直接 push_back 到对应 vector 尾部
• 删除实体时，不是 erase 中间元素（会破坏连续性），而是用末尾元素覆盖被删位置，再 pop_back
• 组件增删会触发 Archetype 切换：实体数据从旧 Archetype 搬到新 Archetype，开销是一次 memcpy，但换来后续 N 次遍历的缓存友好

Sparse Set 如何加速实体 ID 查找

实体 ID 通常是稀疏整数（比如删过 ID=5 的实体，剩下 0,1,2,3,4,6,7…），直接用 std::vector 存储会导致大量空洞。Sparse Set 用两个数组配合解决这个问题：

• m_dense：连续数组，存当前所有有效实体 ID（顺序不保证，但紧凑）
• m_sparse：大小等于最大可能 ID 的数组，m_sparse[id] 存该 ID 在 m_dense 中的索引；若 ID 无效，则值为 -1 或超出 m_dense.size()

这样查某个 ID 是否存在、获取其内部索引，都是 O(1)；插入/删除也是 O(1)（插入追加到 m_dense 并更新 m_sparse，删除则交换末尾元素并更新两个数组）。

// 简化版 SparseSet::contains 实现
bool contains(EntityID id) const {
    return id < m_sparse.size() && m_sparse[id] < m_dense.size() && m_dense[m_sparse[id]] == id;
}

Archetype 和 Sparse Set 怎么协同工作

Archetype 管「数据怎么放」，Sparse Set 管「实体 ID 怎么映射」，两者分工明确但必须对齐：

• 每个 Archetype 内部维护自己的 Sparse Set（或等价结构），用于快速定位某实体在该 Archetype 数据数组中的偏移
• 全局 Entity Manager 用一个 Sparse Set 记录所有活跃实体，同时保存每个实体当前所属的 Archetype 指针/ID
• 当系统要处理 Position + Velocity，它只遍历对应 Archetype 的数据块，而不用扫描全部实体——Sparse Set 确保这个“查找 Archetype”过程不拖慢整体

如果只用 Archetype 不管 ID 映射，那每次通过 ID 查组件就得线性扫所有 Archetype；如果只用 Sparse Set 不分 Archetype，那遍历组件时又回到内存不连续的老问题。

容易被忽略的内存细节

真正影响性能的不是“用了没用”，而是具体怎么布局：

• Archetype 内部组件存储建议按 SoA（Structure of Arrays）而非 AoS（Array of Structures），比如 std::vector positions_x; 和 std::vector positions_y; 分开，方便 SIMD 向量化
• Sparse Set 的 m_sparse 数组如果太大（比如支持 2^32 个 ID），会吃掉几 GB 内存——实际项目常用 16 位或 24 位 ID，配合分段 Sparse Set 或哈希 fallback
• Archetype 切换时的数据搬运，若组件含非 trivial 构造/析构（比如 std::string），memcpy 会出错；必须用 placement new + 析构函数手动管理

这些细节不写进代码注释、不测 cache miss 率、不看 perf report，很容易以为“架构对了就一定快”。