数据布局比类设计更重要，DoD要求放弃“对象即单元”思维，聚焦内存访问模式优化缓存、SIMD和分支预测；推荐结构体数组、热冷数据分离、手动对齐关键字段、SoA/AoSoA布局及裸索引循环。
数据布局比类设计更重要
DoD 不是给 class 换个名字，而是彻底放弃“对象即单元”的直觉。性能瓶颈往往来自 CPU 缓存行反复加载、分支预测失败、SIMD 指令无法对齐——这些全由内存访问模式决定，和虚函数表、继承链无关。
实操建议：
- 把逻辑上一批处理的同类型数据，用结构体数组（
std::vector<Position>）而非对象数组（std::vector<Entity*>）组织 - 避免在结构体内混存热/冷数据：比如
Position和DebugName绝不放同一个 struct；前者每帧读写，后者只调试时查 - 手动对齐关键字段：用
alignas(32)确保float4数组能被 AVX 加载，但别盲目对齐整个 struct——浪费空间反而降低缓存效率
用 SoA 或 AoSoA 替代纯 AoS
标准 std::vector<Transform> 是 Array of Structs（AoS），每个 Transform 含 position、rotation、scale。但物理更新时，你其实只想批量算所有 position，根本不需要穿插读 rotation。
常见错误现象：for (auto& t : transforms) { t.position += t.velocity * dt; } 看似简洁，实际导致缓存行大量浪费——每次加载一个 Transform，只用其中 12 字节，其余 36 字节（假设 48 字节 struct）白读了。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 拆成三个平行数组：
std::vector<glm::vec3> positions;、std::vector<glm::quat> rotations;、std::vector<glm::vec3> scales; - 更进一步，用 AoSoA（Array of Struct-of-Arrays）：每块 4/8 个元素打包，如
struct TransformSoA4 { glm::vec3 pos[4]; glm::quat rot[4]; };，兼顾 SIMD 和缓存局部性 - 别用
std::vector<std::unique_ptr<T>>存数据——指针跳转直接杀死缓存友好性
系统层必须裸写循环，绕过 STL 迭代器抽象
STL 的 std::for_each、范围 for 循环在 DoD 场景下是隐形性能杀手。编译器很难对迭代器解引用做向量化，且 debug 模式下迭代器有额外检查开销。
使用场景：粒子模拟、骨骼蒙皮、碰撞检测等每帧执行数千次的紧循环。
实操建议：
- 显式用索引遍历：
for (size_t i = 0; i ，让编译器清楚知道无别名、可自动向量化 - 手动展开小循环（如 4 次）并用
__m128/simd::float4处理，比依赖 auto-vectorization 更可靠 - 禁用异常和 RTTI：CMake 中加
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -fno-rtti")，减少间接跳转和虚表查找
组件系统不是 OOP 的变体，而是数据注册表
很多团队把 Component 写成带虚函数的基类，再用 std::map<type_id, std::unique_ptr<Component>> 存储——这完全违背 DoD。虚函数调用、动态分配、哈希查找，三重缓存不友好。
性能影响：一次组件查询可能触发 3–5 次随机内存访问，远超连续数组遍历的 1 次预取。
实操建议：
- 组件数据全部扁平化到连续内存池中，例如
struct PositionPool { std::vector<glm::vec3> data; }; - 实体 ID 只是整数索引（
uint32_t），系统通过索引直接访问对应位置的data[i]，零开销 - 用位掩码（
uint64_t archetype_mask）标记哪些组件属于同一数据布局，批量处理同构实体组，避免运行时类型判断
真正难的不是写对 SoA 或对齐字段，而是说服自己：那个优雅的 entity->get<Position>() 接口，就是性能敌人。删掉它，接受裸指针和索引，才能换来每毫秒多跑几千次计算。
