先交代一下背景我时不时会被问到同一个问题“Python这么慢用来写物理引擎不是自讨苦吃吗”问这话的人通常刚被某个游戏或者仿真项目折磨过或者默认了“物理引擎必须上C”这个流行说法。但我自己实践下来的结论是用Python实现轻量级物理引擎不仅可行而且在教学、快速原型、小型游戏和虚拟仿真实验里非常能打。这篇文章就把我做的轻量级物理引擎的核心算法、设计取舍、性能优化和落地经验完整拆开给后面想动手的人一条已经蹚平的路。这篇文章适合三类人初学游戏开发或仿真、想搞懂物理引擎底层原理的人正在做独立小游戏或轻量仿真、不想引入重型依赖的人以及纯粹对“如何用Python榨出更多性能”感兴趣的家伙。读完之后你能自己写出一个几百行、支持刚体运动、碰撞检测、碰撞响应和基础优化的可运行引擎还能知道它适合放在什么场景里实战。1. 在Python里写物理引擎真的不是自找麻烦1.1 哪些场景值得自己写哪些场景别碰先泼一盆冷水如果你打算做硬核的3A游戏、大规模刚体堆叠商用仿真请直接去用现成引擎别折腾自己。Unity、Godot内置了物理系统Blender和Houdini也集成了成熟的刚体模拟仿真领域还有Mujoco、PyBullet这些专业工具。我在工程里也经常用Mujoco做机器人仿真它的求解器稳定性远超一个Python小引擎。但正因为用过这些重武器我才更清楚轻量级引擎的价值在哪里。自己动手写一个轻量级物理引擎最值得的场景是这几个学习核心原理从积分器到碰撞检测再到约束求解所有环节都能看到完整的数据流。用现成引擎你只会调API自己写一遍才知道物体为什么能弹起来、为什么会有穿透、为什么堆叠物体会抖。快速原型验证想验证一个物理交互玩法是否有趣或者做一个仿真实验用Python脚本改起来简直不要太快。我通常在半小时内就能搭出带碰撞的交互原型。无依赖部署有时我只想要一个不依赖任何外部物理库的解决方案把几百行纯Python代码直接塞进项目解决了网络限制、跨平台编译和第三方库兼容性问题。定制行为游戏里经常会有“不符合真实物理但很好玩”的规则比如惯性强制为零、局部时间冻结自己写引擎可以随意改而魔改现成物理引擎需要深入到C层。另外我的一个真实体会是用Python写物理引擎的最大收益不是引擎本身而是彻底看清了游戏开发和虚拟仿真里“模拟”这件事的天花板在哪。你会明白什么时候应该增加迭代次数提高稳定性什么时候可以大胆跳过一帧不模拟为什么帧率波动会直接导致物体抖动——这些理解在任何一个游戏项目里都值钱。1.2 环境准备与最小模拟循环正式动手之前先把环境理清楚。我的建议是Python 3.10及以上版本开发期用标准库加一个pygame做可视化就够引擎核心不依赖任何第三方库。因为纯Python的数学运算在小型物理引擎里完全够用你不需要一开始就把numpy引进来后面性能优化那章我会具体解释为什么不建议无脑上numpy。假设你已经装好了Python命令行能跑通python --version。这一步如果还卡着去官网下载安装包安装时记得勾选“Add Python to PATH”然后打开终端确认版本即可。开发环境我用的VSCode装好Python扩展后按F5就能调试这个流程并不复杂。物理引擎本质上就是一个不断“前进一步”的循环。无论你的引擎多复杂最核心的结构都长这样class PhysicsWorld: def __init__(self, gravity(0, -9.8)): self.bodies [] self.gravity gravity self.dt 1.0 / 60.0 def step(self): # 1. 施加外力比如重力 for body in self.bodies: body.apply_force(body.mass * self.gravity) # 2. 更新速度与位置——这是积分器的工作 for body in self.bodies: body.integrate(self.dt) # 3. 检测碰撞 pairs self.broad_phase() # 粗检测找出可能碰到的物体对 contacts self.narrow_phase(pairs) # 精检测计算具体接触点 # 4. 解决碰撞——更新速度防止穿透 self.solve_contacts(contacts, iterations8) # 5. 清理本帧施加的力 for body in self.bodies: body.clear_forces()这个step()方法就是你游戏主循环里每帧调用的东西。值得注意的是第4步里的“迭代”概念多个物体堆叠时一次求解往往不够需要迭代8到10次让冲量信息在物体链中传播充分。这个细节直接关系到沙盒类游戏里箱子堆叠是否稳定后面我会专门展开。2. 引擎骨架积分器与刚体结构的取舍2.1 半隐式欧拉为什么比显式欧拉稳物理模拟的起点是积分器——给定当前速度、加速度算出下一帧的位置和速度。这是所有引擎的基础选不好后果非常明显物体越弹越高或者干脆“爆炸”飞出去。最常见的三种积分器是显式欧拉、半隐式欧拉和Verlet。显式欧拉的更新方式是先更新位置、再更新速度# 显式欧拉先位置后速度 body.position body.velocity * dt body.velocity body.acceleration * dt问题在于它默认使用“旧速度”来更新位置导致能量不断累积。用弹簧振荡来测的话你会发现振幅会越来越大最后直接发散。快速验证方法挂一个弹簧摆显式欧拉在1秒内就会疯掉。现场效果很吓人但它纯粹是数学问题不是代码bug。半隐式欧拉则交换了顺序先更新速度、再更新位置# 半隐式欧拉先速度后位置 body.velocity body.acceleration * dt body.position body.velocity * dt这一下就反直觉地变稳定了。原因在于更新位置时用的是“已经施加了当前帧加速度后的新速度”相当于给系统提供了阻尼抑制了能量累积。实现极简稳定性却好一大截。我的引擎默认采用半隐式欧拉这是单纯从“性价比”出发的决定——只用改一行代码就能换来几个数量级的稳定性提升。Verlet积分器也不错它的优势在于不直接存储速度而是根据历史位置推导当前速度能量特性比欧拉类更保守在粒子系统里很受欢迎。但它在刚体模拟里需要维护“上一帧位置”耦合进碰撞处理后反而会更绕。所以我只在做布料粒子测试时用它刚体路径保持半隐式欧拉不变。2.2 刚体数据结构与力的累加流程一个物理引擎的模型核心是刚体。我在设计刚体类时尽量让字段足够少、足够直观class Body: def __init__(self, mass1.0, position(0, 0)): self.mass mass self.inv_mass 1.0 / mass if mass 0 else 0.0 # 物理引擎常用逆质量 self.position list(position) self.velocity [0.0, 0.0] self.angle 0.0 self.angular_velocity 0.0 self.force [0.0, 0.0] self.torque 0.0你可能会问为什么用inv_mass逆质量而不是直接存mass这是物理引擎里的常见约定主要好处有两个一是求解碰撞冲量时1/m1 1/m2这种分母形式可以直接拆成inv_mass1 inv_mass2少几次除法二是静态物体比如地面、墙壁只需要把inv_mass设为0就能天然地“不可移动”这个技巧贯穿所有刚体求解。每一帧的力的累加流程要严格遵守“清空—施加—求解—清空”的循环。如果忘了清空上一帧的重力会一直叠加物体很快飞上天。这个 bug 我调试过整整一个晚上确保每个引擎里都在最前面加一行clear_forces()。累计完力就要考虑转动惯量。刚体不光会平移还会转动转动阻力由转动惯量I决定。复杂形状的转动惯量计算很麻烦但圆形和矩形比较优雅圆形半径 rI 0.5 * m * r^2矩形宽 w 高 hI (1/12) * m * (w^2 h^2)这个参数直接参与角速度、角加速度的计算。开始时你可以偷懒设置默认转动惯量为1.0但一旦加入堆叠场景真实转动惯量是稳定性的关键因素之一。实测下来矩形转动惯量用真实公式后箱子的翻转和堆叠手感立刻自然起来。3. 碰撞检测粗检测和精检测的分层设计3.1 空间哈希网格让检测量从O(n²)降到O(n)碰撞检测是物理引擎里最讲究架构的部分也是性能优化的主战场。最简单粗暴的算法当然是双双比较O(n²)遍历所有物体对。100个物体时没关系但如果塞进1000个球每帧要做50万次距离判断Python直接卡成幻灯片。我的解法是经典的空间哈希网格把世界按格子划分每个格子只容纳可能相交的物体做检测时不需要全场景遍历只要检查当前物体和它周围3x3网格里的邻居即可。原理跟你去图书馆找书一样——先确定区域再在区域内逐排搜索而不是从一楼跑到顶楼每一本书都看一遍。核心实现并不长class SpatialHashGrid: def __init__(self, cell_size2.0): self.cell_size cell_size self.grid {} def _key(self, x, y): # 将二维坐标映射到格子编号 return int(x // self.cell_size), int(y // self.cell_size) def clear(self): self.grid.clear() def insert(self, body): x, y body.position key self._key(x, y) self.grid.setdefault(key, []).append(body) def query_neighbors(self, body): x, y body.position cx, cy self._key(x, y) neighbors [] for dx in (-1, 0, 1): for dy in (-1, 0, 1): cell self.grid.get((cx dx, cy dy)) if cell: neighbors.extend(cell) return neighbors格子大小cell_size是个关键参数。我的经验法则是取“场景中物体平均直径”的1到1.5倍太大一个格子装太多物体检测效率退化太小一个物体横跨多个格子需要查询更多格子而且插入操作更频繁。以1000个球、直径0.5的场景为例cell_size0.8的实测性能比cell_size2.0高出约30%。3.2 碰撞对去重与基本图元的相交测试空间哈希网格筛出来的邻居里会有大量重复A出现在B的邻格B也会出现在A的邻格但物理上你只需要处理一次碰撞对。我给每个物体加了一个递增的id用一个集合对(min_id, max_id)去重就能天然避免重复处理。去重之后进入精检测阶段。我建议从三种最基本的碰撞对开始支持圆-圆、圆-AABB轴对齐矩形、AABB-AABB。这一步是引擎里最有“几何味”的部分def circle_circle(a, b): dx b.position[0] - a.position[0] dy b.position[1] - a.position[1] r_sum a.radius b.radius dist_sq dx * dx dy * dy if dist_sq r_sum * r_sum: return None dist math.sqrt(dist_sq) normal (dx / dist, dy / dist) if dist 0 else (0, 1) penetration r_sum - dist return normal, penetration圆-圆检测只有一行距离判断核心公式就是勾股定理。dist_sq r_sum * r_sum用平方比较是为了省掉一次昂贵的开根号运算——当大量碰撞对根本不接触时这个优化能省下很多时间。圆-AABB 检测稍微绕一点把圆心投影到矩形内部找到距离圆心最近的矩形内点再计算圆心到该点距离并与半径比较。这是“点到矩形距离”的几何题代码量不大但非常关键因为很多游戏的角色碰撞体积都用AABB表示。等你要做凸多边形碰撞时主线思路是分离轴定理SAT如果两个凸多边形不相交一定能找到一条分离轴使得多边形在其上的投影不相交。这个数学结论很优雅但实现复杂度高不少。我的建议是先让圆和矩形跑通整个引擎闭环再加入多边形支持不迟。4. 碰撞响应脉冲法约束求解的完整实现4.1 从法向冲量公式开始找到碰撞点和穿透深度之后下一步是让物体“弹开”。我采用的是主流物理引擎包括Box2D、Chipmunk都在用的脉冲法通过瞬间改变速度来模拟碰撞力而不是直接在碰撞帧里推位置。这个“先速度后位置”的思路和半隐式欧拉一脉相承能保持模拟稳定性。假设两个物体A和B在接触点碰撞法向量为n由A指向B。它们沿法向的相对速度为v_rel_n dot(v_A - v_B, n)碰前相对速度如果是负值说明两个物体正在接近如果为正值说明正在分离不需要处理。我们想要的效果是碰后相对速度变成-e倍碰前相对速度这里的e是恢复系数0为完全非弹性1为完全弹性。由此可以解出冲量大小j -(1 e) * v_rel_n / (inv_mass_A inv_mass_B)这个公式是牛顿碰撞定律的离散化形式也是脉冲法求解器里最核心的计算语句。对应到代码def resolve_contact(a, b, normal, penetration): rel_vel (a.velocity[0] - b.velocity[0], a.velocity[1] - b.velocity[1]) rel_vel_n rel_vel[0] * normal[0] rel_vel[1] * normal[1] if rel_vel_n 0: return restitution 0.5 inv_mass_sum a.inv_mass b.inv_mass if inv_mass_sum 0: return j -(1 restitution) * rel_vel_n / inv_mass_sum impulse (normal[0] * j, normal[1] * j) a.velocity[0] impulse[0] * a.inv_mass a.velocity[1] impulse[1] * a.inv_mass b.velocity[0] - impulse[0] * b.inv_mass b.velocity[1] - impulse[1] * b.inv_mass这里有个关键点j的正负和方向直接决定了冲量是推还是拉。实际操作中我会保持统一的约定法向从A指向B避免求解方向错乱。恢复系数的默认值 0.5 适合大多数游戏场景——既保留了明显的弹跳感又不至于像弹力球一样停不下来。如果希望更物理正确恢复系数还应该与相对速度挂钩低速时e接近0高速时才明显弹起这是引擎进阶版本该做的事第一版可以先固定常数。4.2 摩擦、位置修正和迭代求解的细节一个能弹起来的引擎已经能玩但离“能用的物理引擎”还差三块拼图摩擦力、位置修正、迭代求解。摩擦力我采用了简化版的库仑摩擦模型取碰撞点切向方向计算切向相对速度然后给出一个与法向冲量大小成比例的冲量边界是j * friction_coeff。这个“裁剪”操作保证摩擦力不会反向推动物体或产生自激振荡def apply_friction(a, b, normal, j): tangent (-normal[1], normal[0]) rel_vel_t (b.velocity[0] - a.velocity[0]) * tangent[0] \ (b.velocity[1] - a.velocity[1]) * tangent[1] jt -rel_vel_t / (a.inv_mass b.inv_mass) max_friction j * friction_coeff if jt max_friction: jt max_friction elif jt -max_friction: jt -max_friction a.velocity[0] - jt * tangent[0] * a.inv_mass a.velocity[1] - jt * tangent[1] * a.inv_mass b.velocity[0] jt * tangent[0] * b.inv_mass b.velocity[1] jt * tangent[1] * b.inv_mass摩擦系数我默认给到0.30.6之间。狐狸尾巴就藏在你的游戏手感里摩擦太大移动平台上的物体会被“黏住”太小物体像在冰面上滑冰。这个没有统一标准我的经验是一边跑一边调手感对了就固定。位置修正解决的是穿透。脉冲法只能改变速度改不了已经发生的重叠量。如果物体在一个时间步里钻进了地面5像素你会眼睁睁看到它陷进去。解决办法是Baumgarte位置修正按一定百分比把重叠量直接推出来。percent 0.2 slop 0.01 correction max(penetration - slop, 0.0) / (a.inv_mass b.inv_mass) * percent correction_vec (normal[0] * correction, normal[1] * correction) a.position[0] correction_vec[0] * a.inv_mass a.position[1] correction_vec[1] * a.inv_mass b.position[0] - correction_vec[0] * b.inv_mass b.position[1] - correction_vec[1] * b.inv_mass这里的percent0.2意味着每帧只推出20%的穿透量slop0.01则是允许极小的穿透不加修正。为什么不全推出去全推出去虽然能立刻消除穿透却会让物体产生额外的“弹跳能量”堆叠场景会抖成筛子。只修正一部分并允许微小渗透系统才能稳定收敛。这两个参数看似闲笔其实直接决定堆叠的手感。迭代求解是把单次碰撞求解变成循环。你放四个箱子堆在一起时先处理上面两箱的碰撞再处理下面两箱下面的箱子会被推走一点如果只求解一轮上面的箱子必然会陷入地面。所以solve_contacts要跑8~10轮让冲量信息在堆叠链里传播到位。这里的时间和精度取一个平衡每帧迭代8次在100个物体内效果很好物体数量超过500后迭代次数过多会成为瓶颈后面优化章节我会具体讲怎么取舍。5. 性能优化实测数据与三个立竿见影的优化手法5.1 不要凭感觉优化Profile 先走一遍我见过太多人一上来就纠结“Python慢”然后把所有数据结构换成__slots__、把数组换成numpy结果发现瓶颈根本不在那里。正确的流程是先测再改。我写了一个压测脚本随机生成不同数量的球从高处自然堆落每秒叫world.step()60次再用cProfile和line_profiler定位热点。python -m cProfile -s cumulative benchmark.py1000个球的实测热点分布大致是这样的环节耗时占比说明精检测圆-圆40%~50%距离计算虽然简单但碰撞对数量大粗检测空间哈希15%~20%建立网格、查询邻居、去重的成本碰撞响应脉冲法15%~20%每个接触对都要做摩擦和位置修正积分器10%左右每个物体做一次速度/位置更新其他外力、清空5%~10%力累加与清理精检测是绝对热点。我当时第一反应是优化距离计算本身但后来发现更大的收益在“减少精检测调用次数”。方案很简单在粗检测里就提前做一个AABB包围盒快速筛选把显然不相交的圆对提前丢掉减少开根号和距离平方计算。这个发现也印证了一个原则先确认瓶颈在哪个环节再决定优化手段。凭感觉把循环里某个乘法改快往往一无所获。5.2 三个我实测有效的优化手段第一个是局部变量缓存属性访问。Python的属性查找尤其是经过self.链式访问时比局部变量慢一个数量级。我把热点循环里的属性访问改成局部变量缓存后1000个球场景直接快20%。以碰撞响应为例# 慢版本每次都通过对象属性访问 a.velocity[0] impulse[0] * a.inv_mass # 快版本循环外缓存局部引用 vel_a a.velocity inv_a a.inv_mass vel_a[0] impulse[0] * inv_a这里有个细节a.velocity本身是个list直接改list里的元素不会改变引用所以缓存vel_a后修改list内容是安全的。但如果把a.velocity赋给vel_a再把vel_a重新赋成新list就会断掉引用让修改失效。这个坑我踩过顺手记在这里。第二个是睡眠机制。很多物体在堆积完成后其实处于“睡着”状态位置和速度变化极小根本不值得继续做碰撞检测和求解。我给每帧速度和角速度都低于阈值的物体打上睡眠标记睡眠中的物体不再参与积分和碰撞检测除非有活跃物体撞到它或者受到外力。这个优化非常接近游戏引擎的“对象惰性求值”思路。1000个球堆积稳定后活跃物体数量可能只剩下10%耗时成倍下降。实测数据是从每毫秒级降到不到0.1毫秒效果肉眼可见。SLEEP_SPEED_SQ 0.01 * 0.01 def update_sleep(body, dt): speed_sq body.velocity[0] ** 2 body.velocity[1] ** 2 if speed_sq SLEEP_SPEED_SQ and abs(body.angular_velocity) 0.01: body.sleep_timer dt if body.sleep_timer 0.3: body.sleeping True else: body.sleep_timer 0 body.sleeping False注意唤醒机制要“宁醒勿困”如果有活跃物体进入睡眠物体邻域必须立刻把它唤醒否则会出现“穿模”和“幽灵穿透”。我实现的做法是每次碰撞检测遇到睡眠物体时只要另一个物体不是睡眠状态就同时唤醒两者。第三个是对象池范式域减少GC压力。物理引擎每帧要产生大量临时对象特别是接触点Contact。Python的垃圾回收器在大量临时对象下会频繁触发导致帧率尖峰。我的做法是为Contact建立对象池用完回收复用class ContactPool: def __init__(self): self._pool [] def acquire(self): if self._pool: return self._pool.pop() return Contact() def release(self, contact): contact.reset() self._pool.append(contact)对象池优化后10秒的堆叠测试中GC触发次数从几百次降到几乎为0。这种优化对小规模场景提升不明显但物体一多帧率稳定性差距非常明显。完整压测数据在1000个球、每个球半径0.2、场景大小20x20时表现如下优化阶段平均单帧耗时帧率目标60fps初始版本无空间哈希16.2 ms约62帧明显卡顿加入空间哈希与去重5.8 ms稳定60帧局部变量缓存与睡眠机制1.4 ms稳定200帧再加对象池1.1 ms长期运行无GC尖峰可以看出真正的大头是“架构级优化”空间哈希和“算法级优化”睡眠而不是“语法级优化”装numpy。所以哪个先做、哪个后做心里要有数。6. 从引擎到应用游戏开发和虚拟仿真的部署与取舍6.1 游戏开发里怎么用这套引擎游戏开发场景下物理引擎必须能无缝嵌入游戏循环。一个值得推荐的接口设计是物理层与渲染层彻底分离。你的游戏里有角色、NPC、招式动画但物理引擎不关心这些它只管理“有物理属性的body”的位置和旋转。渲染层每帧从body读取位置画出来就行。我推荐的模式是让PhysicsWorld只做模拟游戏对象通过body.user_data引用回游戏逻辑实体。这样你可以在一个step()里更新完物理拿到所有body位置后统一交给渲染class GameActor: def __init__(self, visual_id): self.visual_id visual_id self.body Body(mass1.0, position(0, 0)) self.body.user_data self # 物理世界不关心这个但游戏层用得上 # 每帧 world.step() for actor in actors: x, y actor.body.position renderer.draw(actor.visual_id, x, y, actor.body.angle)我还用这套引擎做过一个小的打砖块游戏demo。核心玩法是挡板弹球、砖块破碎和掉落道具。引擎只提供了球与挡板的碰撞反弹、球与砖块的碰撞反弹以及砖块受击后消失的流程。整个过程不需要完整约束求解只需要碰撞检测和脉冲响应性能余量很大。这就是我前面强调的“按需取用”游戏里不一定需要所有物理特性按项目需求剪裁引擎才是自制引擎最大的价值。在很多游戏项目里引擎内置物理吸引人之处常常是“物理表现”特效、破碎、布娃娃、关节这些在轻量级引擎里要么只能做很简陋的版本要么做不了。所以如果你需要这类功能最好直接在Godot、Unity这类引擎里做它们物理系统的完整度远超自制。我不否认这一点——但正是因为知道了自制引擎的天花板选型时才不会纠结。6.2 虚拟仿真中稳定性优先参数整定心得游戏场景追求“看起来对”虚拟仿真场景则追求“数值上稳”。同一个引擎在这两类场景里的参数配置差异很大。我把自己的引擎同时跑过游戏demo和仿真实验参数整定心得如下参数游戏推荐仿真推荐影响固定时间步长 dt1/60s1/240s或更小dt越小越稳定但也越慢求解迭代次数4~810~20决定堆叠稳定性的上限恢复系数 e0.3~0.8看手感0.1~0.3决定碰撞能量损失摩擦系数0.2~0.50.5~0.9决定物体能否稳定站立位置修正百分比0.2~0.30.3~0.5过大容易抖动过小容易穿透一个常见误区觉得仿真只要把时间步长调到极小就万事大吉。实际上只要迭代次数不够物体堆叠依然会缓慢漂移。固定时间步长和迭代次数是一对孪生变量——dt减少模拟次数增加每次步进更准迭代增加接触信息传播更充分。我在做虚拟仿真实验时习惯把dt设为1/240迭代次数设为16这样静止堆叠的漂移可以忽略不计。这里顺带提一下为什么我不建议在轻量级场景里无脑换专业仿真引擎。我在机器人项目里经常用Mujoco它的求解器在接触稳定性上确实比自制引擎强太多。但它的学习成本、配置复杂度、平台依赖也很明显——如果你的目标是做一个“小球在斜坡上滚”的简单教学演示或者做一个比赛用的游戏物理冰面杀鸡用牛刀反而拖慢开发节奏。自己做的东西你完全清楚它每一步在干什么调试起来比黑盒快得多。6.3 浮点精度、帧率波动和物理参数的单位世界观最后再分享一个容易踩坑的点物理引擎里的单位。游戏里常常把“1个引擎单位”直接映射成“1像素”这在数值稳定性上是大忌。我之前在像素坐标系里直接跑物理item_dt1/60重力设置成(0, 9.8)结果物体几乎看不出下落因为像素值太小重力加速度每帧只改变不到0.003像素速度完全被舍入误差吞掉了。我把坐标系改成“1单位50像素”并且重力调整为(0, -9.8)单位距离对应米物理表现立刻正常。后面养成习惯先用真实的物理单位米、千克、秒设计引擎渲染时再做换算。浮点精度问题到了大型场景才会明显。一个物体在原点运行10000帧后位置值越积越大很多小增量会被吞掉。解决办法之一是用相对坐标游戏相机对准某个中心点时body的位置以相机中心为参考存储而不是以世界原点为参考。这个在设计存档系统、大地图游戏时尤其重要自制引擎的0.0001精度提升往往比加一堆新功能更实在。说到参数和稳定性我做虚拟仿真时最深刻的体会其实是大部分“物理引擎的bug”根本不是引擎的问题而是单位不一致或参数超出合理范围导致的问题。重力设成9800任何引擎都会爆炸恢复系数设成2任何引擎都会越弹越高。遇到异常表现先复盘这几个值能少踩很多坑。如果你现在正打算用Python写一个轻量级物理引擎我的建议是别一开始就去对标PhysX和Mujoco先跑通一个“重力作用下的球体下落、碰撞、弹起、堆叠”的完整闭环再一步步加入摩擦力、位置修正、睡眠机制。每加一个功能你都会更理解物理引擎里抽象与取舍的精髓。这个过程本身比最终产出几十行可运行的代码更值钱。