浏览器里也想跑“硬核物理”：这个 WebGPU 开源项目，正在把网页变成小型仿真实验场
一个小众开源项目，为什么值得科技媒体认真看一眼
GitHub 上最近出现了一个不算热闹、却很容易让技术圈兴奋起来的项目：webphysics。它来自开发者 jure，是一个基于 WebGPU 的实验性物理引擎，核心围绕一种 AVBD 风格的求解器展开，用来处理刚体和软体的物理模拟。项目现在的状态很坦诚：它还不是“装上就能商用”的模块，浏览器支持也很有限，目前主要跑在 Chrome 上，更像一份“概念验证”。但恰恰是这种早期形态，往往最能暴露下一波技术趋势的轮廓。
过去很多人对“网页物理引擎”的印象，大概还停留在小游戏、弹球、布料晃动，或者某些 Three.js Demo 里那个永远在抖的软体立方体。能在浏览器里跑，已经很不错；至于严肃一点的碰撞、约束、摩擦、并行求解，那通常被认为属于原生引擎、桌面模拟器，或者游戏主机的领地。webphysics 让我觉得有意思的地方，在于它不是简单把旧时代的 CPU 逻辑硬塞进网页，而是顺着 WebGPU 这条路，试图从一开始就把浏览器当作 GPU 计算平台来看待。
这背后有一种很鲜明的时代气息：浏览器不甘心只当“文档阅读器”了。它先后吞下了视频编辑、3D 建模、AI 推理、协同办公，如今又开始伸手去碰实时物理。你可以说这是前端世界的野心，也可以说是开发者对“安装软件”这件事越来越没有耐心。只要点开一个链接，就能看到复杂仿真，这种体验对教育、创作、工业可视化甚至电商展示都很有诱惑力。
AVBD 不只是论文名词，它代表了一种更现代的求解思路
webphysics 的技术核心，来自一篇相当前沿的论文：Augmented Vertex Block Descent，也就是 AVBD。项目 README 里明确写到，它遵循了论文中的整体流程：从碰撞检测开始，经过 broad phase、narrow phase、接触流形、warm start、着色并行求解、对偶变量更新，到最终速度重建。这一串词看起来很学院派，但如果说得更直白一点，它想解决的问题其实非常朴素：让很多物体在互相碰撞、挤压、摩擦的时候，既算得快，又尽量算得稳。
物理引擎行业其实一直在和两个老问题缠斗。一个叫性能，一个叫稳定性。你把场景做复杂一点，物体多一点，或者加上软体、关节、弹簧，模拟就会迅速变贵。另一边，如果求解不够稳定，就会出现“穿模”“抖动”“粘住”“突然弹飞”这些玩家很熟、开发者更熟的经典灾难现场。传统引擎比如 Box2D、Bullet、PhysX、Havok，各有各的拿手活，也各自背着历史包袱。AVBD 这类新方法吸引人的地方，是它在并行求解和复杂约束处理上展现出了一种新的可能性，尤其适合 GPU 这样的并行硬件。
这也是 webphysics 最大的野心：它不是给网页补一个物理特效插件，而是试图验证一种新一代求解器，能否在 WebGPU 时代真正落地。项目里甚至专门提到了 LBVH 结构来做 broad phase 候选碰撞对生成，这说明作者并不满足于“看起来能动”，而是在认真搭建一套适合 GPU 的完整管线。对技术媒体来说，这种项目比“又一个炫酷 Demo”更值得写，因为它有方法论，有路线图，也有明确的工程取舍。
WebGPU 终于让浏览器物理，不再总是“差点意思”
如果把时间拨回三五年前，在浏览器里做高性能物理仿真基本是一种带着悲壮感的工程行为。WebGL 更擅长图形渲染，不太适合通用计算；JavaScript 再怎么优化，也很难和原生 C++ 引擎正面硬碰。于是很多网页上的“物理效果”，本质上更像预烘焙动画加一点交互包装，真遇上复杂碰撞和大规模并行就露馅。
WebGPU 的出现改变了叙事方式。它不是 WebGL 的小修小补，而是把现代 GPU 编程模型更直接地带进了浏览器，允许开发者更合理地调度 buffer、compute shader 和并行任务。这意味着前端开发者第一次有机会在网页里认真谈“计算管线”，而不只是“画面怎么渲染”。webphysics 的存在，就是这种变化的一个缩影：碰撞检测、约束构建、求解步骤都可以尽量放到 GPU 上，浏览器终于不再像以前那样只能在旁边打下手。
我甚至觉得，这比很多“浏览器里跑大模型”的新闻更有现实感。因为 AI 推理虽然热闹，但对普通用户来说，很多体验仍然和云端服务深度绑定。物理仿真不一样，它天然适合交互、教育和可视化，本地跑起来就有即时反馈。想象一下，一个机械工程课程页面，学生打开浏览器就能拖动零件看碰撞和应力趋势；一个家具电商页面，沙发垫、弹簧、布料不再是录好的动画，而是真的能对用户操作作出近似真实的反应；或者一个游戏原型团队，开个链接就能让所有成员在同一套环境里测试物理效果。以前这些事不是做不到，而是太麻烦、太贵、太依赖特定平台。
它还很早，也正因为早，所以问题更值得问
当然，别急着把 webphysics 吹成“网页版 PhysX”。从项目现状来看，它还非常早期。GitHub 页面显示，目前 star 数不算夸张，提交历史也不长，README 甚至直接提醒：这不是即插即用模块，只是初步验证，浏览器支持也有限。换句话说，它现在更像一座搭好的脚手架，而不是已经装修完毕的大楼。
问题也非常现实。第一，WebGPU 的跨浏览器普及仍然不够彻底。Chrome 先跑起来，不等于整个 Web 平台已经万事俱备。只要 Safari 和 Firefox 的支持、性能、兼容性还不够一致，真正面向大众的产品就会很谨慎。第二，物理引擎从“能跑”到“可信赖”之间隔着大量工程细节。接触稳定性、时间步长、不同硬件上的一致性、调试工具、开发者 API 设计，这些都不是论文里最显眼的部分，却决定了项目能不能走出实验室气质。
还有一个更值得琢磨的争议点：网页端高性能物理到底是不是刚需？ 这问题听上去有点泼冷水，但必须问。因为不是每个技术突破都会变成大众产品。很多时候，浏览器里能做，并不代表商业上值得做。原生应用仍然在性能、系统权限、设备整合上占优。尤其在游戏领域，大型商业作品短期内不太可能因为一个 WebGPU 物理引擎就转向网页发行。
但如果把视野放宽一点，答案就没那么悲观了。网页物理不必替代原生，它更可能在轻量级交互仿真、教育、可视化、远程协作、数字孪生预览这些场景先站稳脚跟。就像 Figma 并没有消灭所有桌面设计软件，却重塑了协作设计的工作流；Web-based IDE 也没有淘汰本地开发环境，但改变了很多人的入口。webphysics 真正可能撬动的，也许不是 AAA 游戏，而是那些过去没人认真服务过的“半专业、强交互、低门槛”场景。
开源世界的迷人之处，就是有人愿意先把难事做出来
从新闻价值看，webphysics 最动人的地方，其实不只是技术指标，而是它延续了开源社区里一种很珍贵的气质：先把别人觉得麻烦、不划算、看上去没那么快变现的事情做出来。作者在 README 里写得很直接，自己热爱高级 Web 图形和开源实验，如果大家想看到更多类似项目，可以支持他的工作。读到这段我会有一点熟悉的感慨——很多真正推动 Web 生态前进的尝试，最开始都不是大公司的 KPI，而是某个开发者对“浏览器应该还能做得更多”的执念。
这也让人想起过去几年 Web 图形领域的演进：从 Three.js 把 3D 带给大批前端开发者，到 Babylon.js、PlayCanvas 等框架不断拓宽边界，再到 WebAssembly、WebGPU 一步步把浏览器从脚本容器升级成更严肃的运行时。今天的 webphysics，也许还只是这个故事中的一个小注脚，但它提醒我们，网页从来不是技术终点的低配版。
如果你是普通用户，这个项目短期内可能只意味着“又一个很酷的 Demo”。如果你是开发者，尤其做图形、游戏、工业可视化、教育软件，你大概会从中看到别的东西：浏览器物理引擎终于有机会摆脱过去那种“能用但将就”的局面，朝着更高并发、更复杂约束、更真实交互的方向迈一步。
我的判断是，webphysics 本身未必会成为下一个现象级基础设施，但它代表的方向非常重要。因为技术浪潮往往不是在大公司发布会上先出现，而是在这种略显粗糙、却思路大胆的开源仓库里，先露出一点锋芒。谁知道呢，也许几年之后，我们会习惯在一个网页标签页里拖动物体、折布料、调机械结构，就像今天习惯在浏览器里剪视频、跑 AI、开设计稿一样自然。