企业官网建设流程全解析

1. 为什么我最终选了 Rust 来写物理引擎——而不是 C++

先说一个可能反直觉的结论：我在动手之前，其实先用 C++ 搭过一个物理引擎的半成品。当时用的是经典的 Bullet 风格架构，刚体、碰撞体、约束求解器全都写在类继承体系里，跑起来也没问题，但当我试图加进多线程、开始做关卡热更新、想把引擎嵌进一个脚本化的游戏框架里时，C++ 版本的内存安全问题就开始不断找上门——不是崩溃就是偶发的数据竞争，排查起来极其耗神。

Rust 解决的就是这一整类问题。

1.1 物理引擎需要的是什么：确定性、低延迟、可控内存

物理引擎不是一个普通的业务系统。它在游戏里每帧要处理成百上千个刚体，在机器人仿真里要处理实时控制回路，在物理模拟里可能要跑几万甚至几十万个粒子的交互。这些场景对运行时行为的要求非常苛刻：

• 确定性：同样的输入必须产生同样的输出，否则联机对战、回放系统、自动化测试都会出问题。
• 低延迟：不能因为内存分配或 GC 停顿导致某帧突然卡顿。
• 内存可控：物理世界是长生命周期的系统，不能频繁分配、释放内存。

这三个需求放在一起，正好踩中了 Rust 的核心优势区。Rust 没有 GC、没有运行时，默认情况下不会在运行时偷偷做垃圾回收；所有内存分配都是显式的，你能清楚地知道什么时候分配、什么时候释放。更关键的是，Rust 通过在编译期保证内存安全和线程安全，把 C++ 里最容易翻车的悬垂指针、数据竞争问题直接挡在了编译器之外。

1.2 和主流物理引擎技术栈的实际对比

市面上成熟的物理引擎大多是 C++ 写的：Bullet、PhysX、Havok 是老牌玩家。Rust 生态里也有 rapier、parry 这样很优秀的库。我当时的判断是：既然目标是“深入理解和可控实现”，不是“快速接入一个现成引擎”，那么自研一个 Rust 物理引擎核心模块反而比改 C++ 引擎更高效，因为每一处代码我都能直接控制，并且不用担心自己写崩了内存。

对比维度上，我整理了当时做选型时的一张表：

这张表不是要说 Rust 全面碾压 C++，而是说对于“从零实现物理引擎核心模块”这个具体目标，Rust 的开发体验是更好的。特别是当你要写碰撞检测、约束求解这种充满算法细节、且极易出现边界 bug 的代码时，编译期帮你看住内存和并发问题，能让你把精力集中在算法本身，而不是段错误。

1.3 选型时也要正视 Rust 的短板

如果你打算跟着做，先别脑热。Rust 做物理引擎也有几个现实问题：

• 编译速度：一旦泛型和 trait 用得比较深，编译时间会明显变长。我在实现约束求解器的时候，一个 3000 行左右的核心文件，增量编译有时候要等 10 秒以上。
• 借用检查器会逼你重新设计数据结构：物理引擎天然是“多个系统共享同一批可变数据”的，比如碰撞检测要读位置、约束求解要写速度，如果一开始数据结构设计得不好，后面会被 borrow checker 折磨得焦头烂额。后面我会专门讲我是怎么绕开这个坑的。
• 生态依赖：Rust 的线性代数库（如 nalgebra、glam）已经很成熟，但如果你需要一些特殊算法，比如特定形式的广义逆求解，可能没有 C++ 那边现成代码多。

我的建议是：如果目标是学习、自研、想要完全可控的物理核心，Rust 是当前综合体验最好的选择；如果目标是快速上线、接入成熟商业引擎，那直接用现成引擎就好，没必要自研。

2. 核心模块架构设计——先在纸上把数据关系想清楚

这是我吃了不少亏之后才总结出来的经验：物理引擎的架构设计，优先级最高的是“数据怎么流动”，而不是“类和模块怎么划分”。Rust 的所有权和借用规则，会逼着你在动手前梳理清楚每个系统读什么、写什么。

2.1 物理引擎核心模块的组成

一个标准的物理引擎核心，拆开来看就这几块：

• 刚体动力学（Rigid Body Dynamics）：负责位置、速度、角速度、力的积分更新。
• 碰撞检测（Collision Detection）：分为 broadphase（粗检测）和 narrowphase（细检测），负责找出物体之间是否接触、接触点在哪儿、法线和穿透深度是多少。
• 约束求解器（Constraint Solver）：负责处理碰撞响应、关节约束、弹簧力等，让物体之间的相互作用符合物理规则。
• 空间数据结构（Spatial Structure）：Broadphase 用的，比如 AABB 树、四叉树、空间哈希网格，用来快速排除不可能碰撞的物体对。
• 时间积分器（Integrator）：数值积分方案的选择，直接决定引擎的稳定性和能量损失特性。

这五个模块在逻辑上是分层的，但在数据上却高度耦合。比如碰撞检测需要读取每个刚体的变换矩阵和碰撞体的形状信息；约束求解器需要读取碰撞检测输出的接触点数据，同时要写入刚体的速度和角速度。

2.2 数据结构设计：用 ECS 思想而不是 OOP 数组堆对象

最开始我用 C++ 写物理引擎的时候，结构是class RigidBody { Vec3 position; Quat rotation; };这种典型的面向对象设计。每个刚体一个对象，系统遍历一个vector<RigidBody>。

这种设计在 Rust 里会遇到一个很直接的麻烦：如果碰撞检测系统持有了&world，约束求解系统也要&mut world，多个系统之间就无法同时运行。Rust 的RefCell和Mutex可以绕，但性能损耗和心智负担都不小。

我最终采用的方案是ECS（Entity Component System）式数据布局，核心思想是：把同一类数据连续存储在一起，系统通过索引访问，而不是持有整个对象的可变引用。

// 一个简化版的数据布局：刚体的位置/速度分开存储 pub struct RigidBodySet { // 每个刚体唯一的索引 id，用 u32 不用 usize 以节省内存 pub positions: Vec<Vec3>, // 位置 pub orientations: Vec<Quat>, // 旋转（四元数） pub lin_vels: Vec<Vec3>, // 线速度 pub ang_vels: Vec<Vec3>, // 角速度 pub inv_masses: Vec<f32>, // 质量的倒数，0 代表无限质量（静态物体） pub inv_inertias: Vec<Mat3>, // 惯性张量的逆 pub active: Vec<bool>, // 是否参与模拟 }

这种设计的核心优势有几点：

• 缓存友好：遍历位置数组时，内存是连续访问的，CPU 缓存命中率远高于指针跳转。
• 系统间并行：碰撞检测系统读positions和orientations，约束求解系统写lin_vels和ang_vels，这两批数据互不冲突，Rust 的所有权模型天然允许你拆分出&和&mut。
• 删除和复用简单：物理引擎经常要销毁物体（比如子弹击中后消失），用索引管理可以在Vec里用swap_remove快速删除。

但这里也有一个细节：如果刚体数量少（比如低于 100），ECS 的 cache 优势不明显；一旦刚体数量上千，尤其在移动端或低配 PC 上，连续内存布局带来的性能差距就很明显了。

2.3 关键模块间的数据流向

我画过一个模块图，不过不依赖任何绘图工具，用文字描述就是：

输入：刚体集合（位置、速度、形状） ↓ [积分器]：根据力和速度更新位置/旋转 ↓ [Broadphase]：用 AABB 快速筛选可能碰撞的对 ↓ [Narrowphase]：对候选对做精确碰撞检测，产出接触点 ↓ [约束求解器]：处理接触和关节约束，产出速度修正 ↓ [积分器]：根据修正后的速度更新位置（半隐式欧拉） ↓ 输出：下一帧的刚体状态（位置、速度、旋转）

这个流程里，最核心的优化点是“尽量少地遍历数据”。比如 broadphase 做完筛选后，narrowphase 只处理那些真正可能碰撞的物体对，而不是全量检测。

3. 刚体动力学与积分器：理论落地到 Rust 代码

物理引擎最底层的部分是刚体动力学，它决定了物体在受力之后怎么运动。这一节从牛顿运动方程开始，直接给出一个可运行的 Rust 实现。

3.1 刚体的运动方程

刚体的运动方程可以拆成两部分：平移和旋转。

平移部分满足牛顿第二定律：

F = m * a a = F / m

因为质量m在模拟过程中一般不变，所以引擎里实际保存的是inv_mass = 1/m，这样计算加速度时直接乘inv_mass就省了一次除法。

旋转部分相对麻烦，要用到角速度ω、力矩τ和惯性张量I：

τ = I * α α = I⁻¹ * τ

这里关键点是：惯性张量是随物体旋转而变化的，所以引擎里保存的是局部惯性张量的逆，然后在每帧根据当前旋转计算世界系下的逆惯性张量。公式是：

I_world_inv = R * I_local_inv * Rᵀ

其中R是当前旋转矩阵，Rᵀ是它的转置。

3.2 数值积分方案的选择

有了运动方程，下一步就是怎么积分。物理引擎中常用三种方案：

游戏开发和大多数实时仿真场景，我推荐半隐式欧拉。它的思路是：先用当前帧的力更新速度，再用新速度更新位置。这个顺序看起来只是一个小改动，但它保证了能量在长时间模拟中不会无限增长，这在玩弹簧摆、陀螺仪这类系统时非常关键。

// 半隐式欧拉积分器 pub fn integrate(positions: &mut [Vec3], orientations: &mut [Quat], lin_vels: &[Vec3], ang_vels: &[Vec3], inv_masses: &[f32], forces: &[Vec3], torques: &[Vec3], dt: f32) { let n = positions.len(); for i in 0..n { // 先更新速度：vel += force * inv_mass * dt lin_vels[i] += forces[i] * inv_masses[i] * dt; // 角加速度 = inv_inertia_world * torque，简化写法： // ang_vels[i] += inv_inertia_world * torques[i] * dt; // 再用新速度更新位置 positions[i] += lin_vels[i] * dt; // 旋转更新：用四元数增量 // orientations[i] = (Quat::from_angle_axis(ang_vels[i] * dt, axis) * orientations[i]).normalize(); } }

这段代码的真实工程版还需要处理惯性张量的世界坐标系变换、四元数规范化（防止浮点误差累积导致非单位四元数）等。但核心逻辑就是这个：先更新速度，再更新位置。

3.3 用 Rust 表达向量和矩阵：自研还是依赖库？

物理引擎离不开向量和矩阵运算。这里有个选择：自己写一个极简的Vec3结构体，还是直接用nalgebra或glam。

我的建议是：学习阶段自己写一个精简版，工程阶段用glam或nalgebra。原因有三：

• 自己写能彻底理解点乘、叉乘、矩阵乘法背后的意义，而不是只会调 API。
• 现成库经过大量优化（SIMD、稳定的数值处理），比你自己写的更可靠。
• 但完全是依赖库的话，一旦需要调试底层数学问题（比如某个旋转异常），你可能会无从下手。

我自己写的最小Vec3大概长这样：

#[derive(Debug, Clone, Copy, PartialEq)] pub struct Vec3 { pub x: f32, pub y: f32, pub z: f32, } impl Vec3 { pub fn new(x: f32, y: f32, z: f32) -> Self { Self { x, y, z } } pub fn dot(self, other: Vec3) -> f32 { self.x * other.x + self.y * other.y + self.z * other.z } pub fn cross(self, other: Vec3) -> Vec3 { Vec3 { x: self.y * other.z - self.z * other.y, y: self.z * other.x - self.x * other.z, z: self.x * other.y - self.y * other.x, } } pub fn length_squared(self) -> f32 { self.dot(self) } pub fn normalize(self) -> Vec3 { let len_sq = self.length_squared(); if len_sq > 0.0 { let inv_len = 1.0 / len_sq.sqrt(); Vec3::new(self.x * inv_len, self.y * inv_len, self.z * inv_len) } else { Vec3::new(0.0, 0.0, 0.0) } } }

注意一个细节：normalize里对零向量做了保护，返回零向量而不是除以零产生 NaN。这种边界处理在物理引擎里非常重要，因为浮点运算中的 NaN 会像瘟疫一样传播，一旦某个刚体的位置变成了 NaN，整个世界的模拟都会崩溃。

3.4 一个实际的弹簧-质点系统示例

为了让上一节的积分器不显得抽象，我写了一个二维弹簧摆的完整示例。假设有一个质点挂在固定点上，受重力和弹簧力作用：

struct SpringMassSim { pos: Vec3, vel: Vec3, anchor: Vec3, k: f32, // 弹簧刚度 rest_length: f32, // 自然长度 damping: f32, // 阻尼系数 } impl SpringMassSim { fn step(&mut self, dt: f32) { // 弹簧力：F = -k * (current_length - rest_length) * direction let delta = self.pos - self.anchor; let len = delta.length(); let direction = delta.normalize(); let spring_force = -self.k * (len - self.rest_length) * direction; // 阻尼力：F_d = -c * v let damping_force = -self.damping * self.vel; // 重力：F_g = m * g，这里 m=1 时加速度 = 9.81 let gravity = Vec3::new(0.0, -9.81, 0.0); let total_force = spring_force + damping_force + gravity; self.vel += total_force * dt; // 质量设为 1 self.pos += self.vel * dt; } }

这个例子虽然简单，但它把上一节的力合成、半隐式欧拉积分完整串起来了。如果你跟着代码跑一遍，会看到质点绕着锚点摆动，并且在阻尼作用下逐渐停下来——这正是物理引擎里弹簧关节、布娃娃系统的基础。

4. 碰撞检测：从 AABB 粗筛到 GJK 细测的 Rust 实现

碰撞检测是物理引擎里最容易出性能问题的部分。如果你对每一个物体对都做精确的几何测试，复杂度是 O(n²)，几千个物体就足够把帧率拖垮。所以工程上必须分两步走：broadphase 和 narrowphase。

4.1 Broadphase：Sweep and Prune 算法

Broadphase 的职责是“快速排除”，不是“精确判断”。最常用的方案是Sweep and Prune（SAP），思路非常直白：

1. 把每个物体投影到三个坐标轴（X、Y、Z）上，得到一个区间 [min, max]。
2. 对每个轴，按照区间的 min 值排序。
3. 遍历排序后的列表，如果一个物体的 max 小于另一个物体的 min，那它们在当前轴上绝对不相交。
4. 三个轴上都不满足“排除条件”的物体对，才进入 narrowphase。

这个算法的原理可以用一个生活类比来理解：想象一排人在一条街上，每个人伸开双臂占一定宽度。如果 A 的右手边没碰到 B 的左手边，那这两个人肯定没有重叠。碰撞检测的 AABB 重叠判断就是这个思路，只不过扩张到了三维。

// 一个简化版的一维 SAP：只看 X 轴 struct AABB { min_x: f32, max_x: f32, // 实际还要有 min_y/max_y/min_z/max_z } fn is_overlap_x(a: &AABB, b: &AABB) -> bool { a.min_x <= b.max_x && b.min_x <= a.max_x }

真正工程化的 SAP 实现，需要对每个轴的区间列表做增量排序，因为前后两帧之间物体移动量很小，列表基本是有序的，用插入排序最坏 O(n²) 但实际接近 O(n)。我实测下来，1000 个物体时 SAP 比两两全量检测快了一个数量级。

4.2 Narrowphase：GJK 算法和它的几个变体

当一对物体通过了 broadphase，进入 narrowphase 时，你需要精确判断“是否接触、接触点在哪、法线方向是什么、穿透深度是多少”。

GJK（Gilbert-Johnson-Keerthi）算法是这里最经典的算法，它用来计算两个凸多面体之间的最近距离，从而判断是否相交。它不基于顶点遍历，而是用**支持函数（support function）**不断构建一个单纯的凸包来计算。

支持函数的意思是：给定一个方向d，返回物体在这个方向上最远的点。对球体来说，支持函数就是球心加半径乘以方向：

fn support_point(center: Vec3, radius: f32, dir: Vec3) -> Vec3 { // 对于球体，最远点 = center + dir.normalized() * radius let dir_len_sq = dir.length_squared(); if dir_len_sq > 0.0 { center + dir * (radius / dir_len_sq.sqrt()) } else { center } }

GJK 的核心流程是维护一个单纯形（simplex，可以理解为点、线段、三角形、四面体），不断向“包含原点的方向”迭代，如果最终单纯形包围了原点，则两物体相交。具体的实现代码比较长，这里不完整贴出，但你可以抓住这个关键思路：GJK 的每一步是找一个方向，然后沿这个方向取两个物体的支持点之差，判断这个差向量能否把单纯形推向原点。

实际项目中我有几个经验：

• 对球体和 AABB 这种简单形状，直接用代数公式检测，不要上 GJK，杀鸡不用牛刀。
• GJK 常搭配EPA（Expanding Polytope Algorithm）来计算穿透深度，因为 GJK 本身只告诉你是不是相交，不给出穿透信息。
• 对地形、静态网格这种复杂几何，GJK 不适用，通常用 BSP 树或体素方案。

4.3 球体 vs AABB 的精确检测实现

作为 narrowphase 的入门，我实现了一个非常常见的场景：球体与 AABB（轴对齐包围盒）的碰撞检测。原理很简单：先找 AABB 上离球心最近的点，然后看这个最近点到球心的距离是否小于半径。

// 求 AABB 上离点 p 最近的点 fn closest_point_on_aabb(p: Vec3, min: Vec3, max: Vec3) -> Vec3 { Vec3::new( p.x.clamp(min.x, max.x), p.y.clamp(min.y, max.y), p.z.clamp(min.z, max.z), ) } fn sphere_aabb_collision(sphere_center: Vec3, sphere_radius: f32, aabb_min: Vec3, aabb_max: Vec3) -> bool { let closest = closest_point_on_aabb(sphere_center, aabb_min, aabb_max); let dist_sq = (closest - sphere_center).length_squared(); dist_sq <= sphere_radius * sphere_radius }

这个方法背后是几何直觉：如果一个球与一个盒子相交，那么盒子上离球心最近的点一定在球内部。如果最近点都不在球里，那整个盒子都在球外。这个思路非常容易扩展：任何凸体之间的碰撞检测，都可以归结为“从一个物体表面找离另一个物体最近的参考点”。

4.4 接触点信息的生成

碰撞检测的产出不能只是一个 bool，还要给约束求解器提供必要信息：

• 碰撞法线n：接触面法线方向，从物体 A 指向物体 B。
• 穿透深度penetration：两个物体重叠的深度。
• 接触点contact_point：实际接触的位置，或一组接触点（面-面接触时要多个点）。

我的实现里把这三个量打包成一个Contact结构体：

pub struct Contact { pub point: Vec3, pub normal: Vec3, pub penetration: f32, }

注意这里有很关键的一个工程细节：穿透深度的计算对浮点误差极为敏感。如果两个物体恰好贴合，浮点误差可能导致微小的穿透或微小的间隙。所以我在生成接触点时，会引入一个很小的参数slop（通常 0.005~0.01 米），小于这个深度就当作不穿透，大于这个深度才产生接触。这个技巧能显著减少“抖动”（jitter）。

5. 约束求解器：序列冲量法让物体真正碰撞反弹

碰撞检测只是“发现”了问题，真正让物体表现出碰撞反弹、滑动、堆叠效果的是约束求解器。这一节讲最难也最值得花功夫的部分。

5.1 约束求解的目标：修正速度

把碰撞还原到物理本质上来看，它其实是一个速度约束。两个物体在接触点处不能互相穿透，所以它们在法线方向的相对速度必须满足一定条件：

• 如果物体正在靠近（相对速度沿法线方向为负），则需要产生一个冲量让它们弹开。
• 如果物体正在分离，则不需要任何处理。

这里的数学表达是：设接触法线为n，接触点处物体 A 和 B 的速度分别为v_a和v_b，那么相对速度在法线方向的分量为：

v_rel_n = (v_b - v_a) · n

碰撞约束要让v_rel_n >= 0（完全弹性碰撞是反弹v_rel_n > 0，完全非弹性碰撞是v_rel_n = 0）。

5.2 序列冲量法（Sequential Impulse）的核心思想

实际引擎普遍使用序列冲量法来求解约束，思路非常符合工程直觉：不一次性算出所有接触点的精确解，而是遍历所有接触点，对每个接触点施加一个冲量修正速度，然后拿修正后的速度去处理下一个接触点，这样反复迭代几轮后，所有接触点都会趋于满足约束。

这就像你手里有几个同时坏掉的灯泡，你不是一次全修好，而是先修好第一个，再去修第二个，第三个……当修回第一个时，它可能又坏了，于是再修一遍。循环几轮之后，所有灯泡最终都能亮。物理引擎里称这个为“迭代求解”，常见迭代次数是 4 到 20 次不等。

5.3 一个球体掉到平面上的碰撞响应代码

假设一个球体以速度v撞向一个静态平面（法线向上n = (0, 1, 0)），我们要计算碰撞后的速度。简化到一维场景（只有 Y 轴速度）：

fn resolve_collision(vel: &mut Vec3, normal: Vec3, restitution: f32) { // 计算法线方向的相对速度分量 let vel_n = vel.dot(normal); // 如果速度在法线方向的分量为负，说明正在靠近 if vel_n < 0.0 { // 冲量。这里质量设为 1（隐式处理） let j = -(1.0 + restitution) * vel_n; *vel += normal * j; } }

这段代码里restitution是恢复系数，取值范围 0~1。0 表示完全非弹性（物体粘在一起，碰撞后法向速度为零），1 表示完全弹性（碰撞后法向速度反向，大小不变）。真实物体的恢复系数通常介于 0.1~0.5 之间。

5.4 加入滑动摩擦后的接触求解

一个碰到底座的立方体如果只有法线方向的碰撞响应，它会像放在完全没有摩擦的冰面上一样滑来滑去。所以约束求解器还需要处理切向摩擦力。

摩擦的物理模型是：计算接触点处的切向相对速度，施加一个与切向方向相反的冲量，但冲量大小要受摩擦系数的限制：

v_rel_t = v_rel - (v_rel · n) * n // 切向相对速度 j_t = -v_rel_t * friction_coefficient

代码上可以这样加：

fn resolve_contact_with_friction(vel_a: &mut Vec3, vel_b: &mut Vec3, normal: Vec3, friction: f32) { let rel_vel = *vel_b - *vel_a; let vel_n = rel_vel.dot(normal); // 法向冲量 if vel_n < 0.0 { let j_n = -(1.0 + RESTITUTION) * vel_n; let impulse = normal * j_n; *vel_a -= impulse; *vel_b += impulse; // 这里假设质量相等且为 1 } // 切向冲量 let rel_vel_after = *vel_b - *vel_a; let vel_t = rel_vel_after - rel_vel_after.dot(normal) * normal; if vel_t.length_squared() > 0.0 { let impulse_t = -vel_t * friction; *vel_a -= impulse_t; *vel_b += impulse_t; } }

这部分的代码边界条件非常多：如果你只处理了法向没有处理切向，物体会像滑冰一样；如果你处理摩擦时没有限制冲量上限，物体会出现“粘住”的假象。完整实现时要引入库仑摩擦模型和冲量截断逻辑。

5.5 约束求解器的迭代组织

真实引擎的约束求解器要处理的不只是碰撞，还有关节约束（球关节、铰链关节）、弹簧马达、鼠标拖拽力等。所以一般会把所有约束统一抽象成一个 trait：

pub trait Constraint { // 用当前速度求解冲量，并写入两个刚体的速度 fn solve(&self, bodies: &mut RigidBodySet, dt: f32); }

然后每一帧的求解循环就是：

for _ in 0..ITERATION_COUNT { for constraint in &constraints { constraint.solve(&mut bodies, dt); } }

这里有个性能与稳定的取舍：迭代次数越多越稳定，但开销线性增长。我的经验值是刚体数量不多（<100）时用 10 次迭代，刚体数量多（>1000）时压到 4 次，再配合 bias factor（偏向因子）补偿穿透深度，效果不错。

6. 性能调优与踩坑实录——Rust 特有的那几个坎

前面把核心模块都实现了之后，真正让它跑得又快又稳，靠的是性能调优阶段。这一阶段我踩了不少 Rust 特有的坑，也总结出很多有价值的实测数据和优化方向。

6.1 最大瓶颈往往在内存分配和系统设计，而不是算法本身

很多新人调优物理引擎时，第一反应是优化碰撞检测算法、换更快的数学函数。但我在实际 profile 之后发现，早期版本的最大性能瓶颈是无意识的堆分配。

Rust 的Vec::push、String拼接、Box::new频繁调用在热路径（每帧执行上万次的路径）会产生大量内存分配开销，这种开销能让引擎帧时间翻倍。我的优化手段是：

• 在引擎启动时预分配好所有Vec的容量，比如Vec::with_capacity(1024)。
• 热路径里避免创建新的Vec，用SmallVec或固定数组代替。
• 用 arena 分配器，把一帧内所有物理对象的内存集中分配，帧结束后统一释放。

我实测的一个直观例子：3000 个球体自由落体，在没有预分配和 arena 优化前，帧时间在 12ms 左右；优化后降到 4ms，提升非常明显。

6.2 借用检查器与物理系统并行的纠纷

前面说过，多系统并行是物理引擎性能的关键。Rust 的 borrow checker 在只有一个大World结构体时会非常难受。我最终采用的策略是把 World 拆分成多个独立的子结构体，例如把positions和velocities分开，让碰撞检测系统只读positions，约束求解系统写velocities，这样就能用rayon做并行迭代：

// 简化版：用 rayon 并行处理 3 个轴上的 broadphase use rayon::prelude::*; fn broadphase_par(objects: &[AABB]) -> Vec<(usize, usize)> { let mut pairs = Vec::new(); // 这里每个轴上的扫描并行执行，最后合并结果 (0..3).into_par_iter().for_each(|axis| { // 按轴排序并扫描 }); pairs }

实际用下来，并行化 broadphase 在四核以上的机器上收益明显。但要注意的是：并行不是免费的，如果物体数量少于 500，创建 rayon 线程池和任务分发的开销反而比单线程更慢。我的原则是：物体数少于 500 就不并行，超过 2000 再果断并行。

6.3 Rust 代码里最常见的三个性能坑

第一个坑是迭代器链滥用。filter、map、collect链式调用写起来很爽，但在热路径上可能产生多次遍历。解决方法是尽量用for循环，或者把多个操作合并成一个循环：

// 低效：两次遍历 let active_indices: Vec<_> = (0..n).filter(|&i| active[i]).collect(); let sum: f32 = active_indices.iter().map(|&i| positions[i].y).sum(); // 高效：一次遍历 let mut sum = 0.0; for (i, &is_active) in active.iter().enumerate() { if is_active { sum += positions[i].y; } }

第二个坑是浮点数非确定性。不同线程的执行顺序不同会导致浮点加法的顺序不同，最终结果出现微小差异。这在单机调试时可能看不出来，但一旦做同步或回放就会出问题。解决方法是在并行求解前先对约束排序，确保每次迭代的处理顺序一致。

第三个坑是编译时间过长。物理引擎代码里大量使用泛型和 trait，很容易让编译器做大量实例化工作。我的缓解方案是把内层循环用具体类型而不是泛型实现，只在系统边界处使用泛型抽象。这个改造让我的编译时间从近 30 秒降到了 15 秒。

6.4 稳定性的工程技巧：休眠系统和穿透修复

最后分享一个很实用的小技巧：物理引擎里绝大部分物体在绝大多数时间是不动的，比如地面、墙壁、堆叠好的箱子。完全没必要每帧都对它们做全套物理模拟。业界通用的做法是休眠系统（sleeping system）：如果一个物体的速度低于某个阈值（比如 0.01 m/s），并且持续一段时间（比如 30 帧），就把它标记为休眠，不再参与积分和碰撞检测，直到被其他活跃物体碰撞才唤醒。

休眠系统对性能的影响是巨大的。我在一个 5000 个物体的堆叠场景里，休眠系统直接砍掉了一半的模拟开销。实现的代码逻辑很简单：

// 简化版休眠判断 if body.lin_vel.length_squared() < SLEEP_LIN_VEL_THRESHOLD_SQ && body.ang_vel.length_squared() < SLEEP_ANG_VEL_THRESHOLD_SQ { body.sleep_timer += dt; if body.sleep_timer > SLEEP_TIME_THRESHOLD { body.is_sleeping = true; } } else { body.sleep_timer = 0.0; body.is_sleeping = false; }

还有一个需要特别小心的点：如果物体一直在缓慢下沉（比如被重力压进地面），速度虽然超过阈值，但位置每帧都在变化，这种场景下休眠系统需要加穿透深度保护，否则会出现“物体穿透墙面还继续被模拟”的bug。我的处理办法是：休眠判断条件里加入最大穿透深度检查，超过 0.1 米就强制唤醒。

对了，如果你是自己从零实现，我建议在加休眠系统之前先加一个可视化调试器，把每个物体的 AABB、速度向量、休眠状态渲染出来。我一开始没有做这个，结果调碰撞检测问题时全靠打印日志，效率低得让人抓狂。后来补了简单的线和框渲染，调试速度直接翻倍。别省这一步，真的。

再补充一个后期比较好用的扩展方向，如果在 Rust 物理引擎核心模块的基础上继续做下去，可以考虑接一个 SIMD 优化的线性代数库（比如wide或手写 SSE/AVX），把向量运算从 4 个 float 变成 4 组 float 并行处理。我做过一个小规模测试，同样的 10000 个球体场景，SIMD 化后的窄相位检测大概有 30% 到 40% 的性能提升。不过这个优化的收益在物体数量少于 1000 时不明显，属于“工程项目后期值得做，学习阶段不必强求”的优化项。