Base-WebGL技术概述
WebGL 自 2011 年由 Khronos 推出，把 OpenGL ES 搬进浏览器，如今几乎所有网页 3D 内容——电商展示、数据可视化、营销互动页、轻量游戏——都跑在它上面。十多年里，围绕这条 API 形成了三类引擎：为 Web 而生的原生引擎（Three.js、Babylon.js、PlayCanvas）、从原生平台移植过来的通用引擎（Unity、Godot、Cocos），以及聚焦垂直场景的小而美引擎（Wonderland Engine、Filament 等）。
格局真正开始松动是 WebGPU 的落地：Chrome 113（2023 年中）首发稳定版，Firefox 于 2025 年在 Windows 上默认启用，Safari 26 也随后跟进。WebGPU 带 Compute Shader，把浏览器渲染能力从”只能画三角形”推到”接近 Vulkan/Metal”，各家引擎的图形后端由此进入 WebGL2 与 WebGPU 双轨期——进度参差，差距被迅速拉开。
衡量一个 WebGL 引擎今天的可用程度，不能只看渲染后端。本文从两个维度盘点：Runtime（图形后端、Compute、材质系统、体积与启动）和 Editor（场景编辑器、可视化材质/管线工具、调试器、协作），最后给出选型建议。
先看全局分层：所有引擎都跑在浏览器提供的同一层图形 API 与运行时上；中层 Runtime 决定了能力上限；上层的 Editor 与工具链决定了实际生产效率。
1. 为什么 Editor 对 Web 引擎格外重要
原生引擎团队衡量”完成度”，通常只看 Runtime 的渲染能力上限。但 Web 引擎的用户构成不同：大量项目来自电商、营销、可视化领域，开发模式是”程序员 + 美术/设计师协作”，交付周期以周计。这决定了 Web 引擎的竞争力有相当一部分在浏览器内可视化工具链上：
- 场景编辑器：摆物体、调光照、配动画，而不是纯手写代码；
- 材质与管线可视化：Node Graph 式的材质编辑器、渲染管线编辑器；
- 调试器：Inspector 式的场景树/Draw Call 检查，Playground 式的即开即用试验场；
- 协作与发布：云端资产管理、一键发布、多人编辑。
后面的盘点里，每家引擎都按这两个维度展开。
2. Web 原生引擎：Three.js、Babylon.js、PlayCanvas
2.1 Three.js
Three.js 是 WebGL 时代的事实标准，但严格说它是一个渲染库而非引擎。Runtime 侧正处于双轨切换期：WebGLRenderer 成熟稳定；WebGPURenderer 自 r167（2024 年中）进入核心构建，WebGPU 不可用时自动回退 WebGL2，同一套材质代码两种后端通用。到 r180（2025 年 9 月）前后，两个渲染器的功能已基本对齐，新特性优先落在 WebGPU 一侧。其核心设计是 TSL（Three.js Shading Language，基于 JavaScript 的节点式着色语言）——材质在节点层面编写，编译到 WGSL 或 GLSL，实现”一份 Shader 跨后端”；目前 TSL 仍标注为 alpha，API 随小版本仍有变动。Compute Shader 仅 WebGPU 后端可用。
Editor 侧是明显短板：官方只有一个极简的场景编辑器，用于摆摆物体、导出 JSON，不具备生产级能力。可视化与协作需求主要靠生态补位——React Three Fiber 做声明式开发，Spline 这类三方工具做设计侧编辑。
- 优势：社区与生态规模最大，例子和三方库极其丰富；包体小、可 tree-shaking；抽象层干净，NPM 化开发体验好；TSL 路线让 Shader 投资跨后端保值。
- 劣势：没有官方级编辑器与调试工具链，团队协作场景弱；WebGPU 迁移期 API 存在震荡（TSL 处于 alpha）；超大场景下 JS 侧场景图的开销会先于 GPU 成为瓶颈。
2.2 Babylon.js
Babylon.js 由微软团队主导，是”全家桶”路线：物理（Havok）、音频、GUI、粒子、加载器全部内置。Runtime 侧 WebGPU 与 WebGL2 双后端并重；v8（2025 年 3 月）引入 Frame Graph 架构，并配套发布了 Node Render Graph——用节点图可视化搭建渲染管线，WebGPU 下可编排 Compute Pass（粒子模拟、GPU 剔除等），WebGL2 下自动降级运行非 Compute 的部分。v8 同时支持了 glTF 的 KHR_interactivity 交互扩展。
Editor/工具链是它最强的部分，而且是浏览器内原生的：Playground（在线试验场，代码即文档）、Inspector（场景树与 GPU 资源调试）、Node Material Editor（节点材质）、Node Render Graph Editor（节点管线）、GUI Editor，外加官方的场景编辑器。这套组合是所有 Web 引擎里最完整的。
- 优势：浏览器内一站式工具链，调试与教学文化极好；API 表面覆盖广，很少需要自己造轮子；微软背书，文档与发布节奏稳定。
- 劣势：默认包体比 Three.js 大，依赖 tree-shaking 控制；极端规模下 JS 侧开销同样存在；Compute 相关能力硬依赖 WebGPU，旧浏览器只能降级。
2.3 PlayCanvas
PlayCanvas 是三家唯一走”云编辑器 + 引擎“一体化的：引擎开源（MIT），编辑器为闭源 SaaS。Runtime 侧，Engine 2 在 2025 年中（v2.9 起）完成了 WebGPU-first 重构，WebGL2 保留为兼容后端；它是第一个把 Compute Shader 用于核心特性的 Web 引擎——3D Gaussian Splatting 的 GPU 排序与渲染，衍生出的 SuperSplat 已成为 splat 编辑与压缩（SOG 格式）的事实工具之一。
Editor 侧，云端编辑器 v2 于 2025 年 10 月正式 GA：React 全面重写，解决了 v1 无法支持多选、剪贴板、拖拽等基础操作的历史包袱；真正的多人实时协作编辑在路线图上，也是这次重写的主要动机。
- 优势：云编辑器 + 资产管理 + 一键发布一体化，最适合”非程序员也要参与”的项目；引擎轻量；在 Gaussian Splatting 方向领先整个 Web 生态。
- 劣势：编辑器闭源且绑定订阅，引擎社区规模小于 Three.js/Babylon.js；编辑器 v1 → v2 的功能迁移尚未完成；部分能力依赖平台方持续投入。
3. 移植型引擎：Unity、Godot、Unreal
3.1 Unity
Unity 的 Editor 完成度是所有候选者里的天花板——但那是原生平台的优势。Web 侧正好相反：导出基于 WASM + WebGL2，功能可用，但体积动辄数十 MB、启动慢、有 4GB 内存上限，移动端浏览器体验长期偏弱。最关键的是 WebGPU 导出跳票：2021 年宣布，2023 年 GDC 放出演示，至今（2025 年后）没有进入任何正式版本，官方不再承诺时间表。Unity 的实际策略已经转向”用 WASM 的新能力（SIMD、线程、Memory64）优化 WebGL 导出”，WebGPU 处于持续演示、持续延后的状态。
- 优势：编辑器与资产生态无可替代；已有 Unity 项目的 Web 版本是”顺手导出”而非重写；一套代码多平台。
- 劣势：Web 是二等公民，加载体验差；WebGPU 遥遥无期，Compute 类特性在 Web 端基本无望；引擎本身不适合纯 Web 团队。
3.2 Godot
Godot 的 Web 导出分两条路：**Compatibility 渲染器（WebGL2）**是默认且推荐的稳定路径；WebGPU 后端自 4.3 起提供实验性支持，构建在轻量级渲染器之上，功能尚不完整（部分后处理、GI 特性缺失），性能也暂不及 WebGL2 路径。另一个 Web 特有的坑是：多线程依赖 SharedArrayBuffer，需要服务器配置 COOP/COEP 响应头。
- 优势：开源免费，编辑器完整，导出体积小于 Unity，独立游戏社区活跃。
- 劣势：Web 端特性缩水明显，WebGPU 实验性；Safari 上的历史兼容问题需要持续测试。
3.3 Unreal：另一条路
Unreal 的 HTML5 导出在 4.24 就已移除。官方的 Web 交付路径是 Pixel Streaming：引擎跑在云端 GPU 服务器上，浏览器通过 WebRTC 收视频流、回传输入。画质上限最高，但每个并发用户都要消耗一台 GPU，本质上是”流媒体”而非 WebGL 渲染，只适合展示类、人数可控的场景。
4. 国产与垂直引擎：Cocos、LayaAir、Galacean、Wonderland、Filament
4.1 Cocos Creator
Cocos 的护城河是编辑器 + 国内小游戏发行链：微信、抖音等小游戏平台一键构建，中文文档齐全，包体小、启动快，正好匹配小游戏平台的硬约束。图形侧采用 GFX 抽象层（Vulkan/Metal/GLES3/WebGL2/WebGPU），WebGPU 后端自 3.8.x 起以实验性形态提供，官方目标是在 4.x 阶段走向成熟；微信小游戏平台本身尚未开放 WebGPU，所以小游戏端仍以 WebGL（高性能模式下映射 Metal）为主。
- 优势：国内小游戏生态最顺手；编辑器完整；Web 构建轻、启动快。
- 劣势：WebGPU 落后国内竞品一拍；3D 表现力与高端渲染特性相对保守；国际生态有限。
4.2 LayaAir
LayaAir 在 WebGPU 上抢了先手：3.3（2025 年 7 月）成为国产首个支持 WebGPU 的 3D 引擎，3.3.1（2025 年 10 月）把 WebGPU 后端推进到 Web 端与微信小游戏端双 Beta，3.4 路线图规划 WebGPU 正式版，并计划提供 Three.js 项目迁移兼容层。IDE 侧是完整的国产编辑器，对小游戏优化深入。
- 优势：WebGPU 起步最早，且覆盖到小游戏端——这是 WebGL 引擎格局里独有的落点；中文生态好。
- 劣势：国际社区小；Beta 阶段的 API 稳定性与特性完整度有待 3.4 验证；生态资产量级不及 Cocos。
4.3 Galacean（原 Oasis）
Galacean 是蚂蚁集团开源的 TypeScript 引擎（前身 Oasis），走”引擎 + Web 编辑器平台”路线，主力场景是电商与互动营销——蚂蚁体系内大量营销页由它支撑。WebGPU 后端在持续推进中，尚未成为主力路径。
- 优势：国内互动营销/电商场景背书扎实，编辑器平台一体化；架构现代，TypeScript 原生。
- 劣势：社区规模小，WebGPU 尚未成熟，国际化程度有限。
4.4 Wonderland Engine
Wonderland 聚焦 WebXR 垂直场景：Runtime 用 C++ 编译为 WASM，性能与体积在 XR 场景下优势明显；编辑器强调迭代速度——打包一秒内完成，热更新直达头显或手机。2026 年上半年更新到 1.6.x，加入了 Meshlet 与 SSAO；WebGPU 后端自 1.2 起以 Beta 形态提供，后续版本的重心更多放在 XR 与资产管线上。
- 优势：WebXR 场景下性能与迭代效率领先；单构建覆盖桌面、移动与头显（含 iOS Safari）。
- 劣势：定位垂直，通用 3D 开发生态小；WebGPU 进展低调，社区以 XR 团队为主。
4.5 Filament
Filament 是 Google 的 C++ PBR 渲染库——注意是库而非引擎，没有场景管理，更没有场景编辑器。它的价值在 PBR 渲染的物理一致性与跨平台嵌入：Android/iOS/桌面/浏览器（WebGL2 后端为主，新增 WebGPU 后端），Google Maps 的 3D 实景瓦片就是它的落地案例。
- 优势：PBR 质量与一致性是库级别的标杆；体积极小，适合嵌入 App 或自定义管线。
- 劣势：场景系统、工具链全部自己搭；Web 侧示例与文档相对滞后；发布节奏近年放缓。
5. 横向对比
| 引擎 | 阵营 | 图形后端 | Compute | Editor 完成度 | 适合场景 |
|---|---|---|---|---|---|
| Three.js | Web 原生（库） | WebGL2 + WebGPU 自动回退 | 仅 WebGPU | 无官方编辑器，生态补位 | 电商、可视化、创意开发 |
| Babylon.js | Web 原生（全家桶） | WebGL2 + WebGPU 并重 | 仅 WebGPU | 最完整的浏览器内工具链 | 重交互 3D Web 应用 |
| PlayCanvas | Web 原生（云编辑器） | WebGPU-first + WebGL2 | 已用于核心特性 | 云编辑器完整，协作开发中 | 轻游戏、营销、Splat |
| Unity | 原生移植 | WebGL2（WebGPU 未 ship） | 无 | 原生编辑器天花板 | 已有 Unity 项目的 Web 补发 |
| Godot | 原生移植 | WebGL2（WebGPU 实验） | 实验性 | 完整、开源 | 独立游戏 Web 版 |
| Cocos Creator | 小游戏向移植 | WebGL2（WebGPU 实验） | 实验性 | 完整（国产） | 微信/小游戏全平台 |
| LayaAir | 小游戏向移植 | WebGL2 + WebGPU Beta（含小游戏端） | Beta | 完整（国产） | 小游戏抢跑 WebGPU |
| Galacean | Web 原生（国内） | WebGL2（WebGPU 推进中） | 推进中 | 平台化编辑器 | 电商互动营销 |
| Wonderland | 垂直（WebXR） | WebGL2 + WebGPU Beta | Beta | 完整（XR 向） | WebXR 展示与培训 |
| Filament | 垂直（渲染库） | WebGL2 + WebGPU 后端 | 有（WebGPU） | 无场景编辑器 | 嵌入式 PBR、3D 瓦片 |
6. 选型建议
- 电商展示、数据可视化、轻创意：Three.js 是默认答案——生态最大、招人容易、包体可控；国内互动营销项目可以看 Galacean。
- 重度交互的 3D Web 应用：Babylon.js。工具链最完整，物理/GUI/加载器全套内置，调试体验是浏览器内最好的。
- 需要美术/设计师深度参与、云端协作：PlayCanvas。云编辑器 + 发布一体化的体验目前没有对手；如果做 Gaussian Splatting，SuperSplat 也几乎必用。
- 微信/小游戏平台：Cocos Creator 是稳妥选择；追求 WebGPU 与更激进的渲染特性，可以关注 LayaAir 3.4 的正式版落地。
- 已有 Unity/UE 项目要上 Web：Unity 走 WebGL 导出（接受加载代价）；UE 项目考虑 Pixel Streaming，但要接受每个并发一台 GPU 的成本。
- WebXR：Wonderland Engine 优先，Three.js/Babylon.js 的 XR 支持作为补充。
- 嵌入原生 App 或自研管线：Filament，或者干脆继续用原生 API。
总结
双轨期的格局可以概括为三句话。第一，Web 原生三家的差距不在渲染而在工具链：渲染后端大家都在朝 WebGPU 走，真正的分水岭是 Editor、调试器与协作能力——Babylon.js 用浏览器内工具链，PlayCanvas 用云编辑器，Three.js 干脆交给生态。第二，移植型引擎的瓶颈是体积与启动，而非功能：Unity 的 WebGPU 跳票说明”把整个引擎塞进浏览器”这条路比想象中难，小游戏平台反而催生出了 Cocos/LayaAir 这类轻量特化路线。第三，Compute Shader 正在改写”浏览器里能做什么”：Gaussian Splatting、GPU 粒子、GPU 剔除这些原先是原生引擎专属的能力，已经开始定义 Web 引擎的下限。
选型时先看平台（哪个浏览器、哪个小游戏渠道）、再看团队形态（是否需要可视化协作）、最后才看渲染特性清单——顺序反了，很容易选一个”demo 好看但流程不顺”的引擎。
参考资料
- three.js WebGPU Roadmap（官方手册）
- three.js 版本状态页（WebGPURenderer/TSL 稳定性）
- Babylon.js 官方博客（v8 发布说明）
- Babylon.js Node Render Graph 文档
- PlayCanvas 官方博客（Engine 2.9 与 Editor v2）
- PlayCanvas Engine 发布页（GitHub Releases）
- Unity WebGL 平台文档
- Unity 公开路线图（渲染/图形）
- Godot Web 导出文档
- LayaAir 3.3 发布公告（国产首个 WebGPU）
- Cocos Creator 下载与更新日志
- Wonderland Engine 官网（版本更新）
- Filament 仓库（GitHub）