WebGL vs WebGPU：浏览器 3D 图形未来在哪
深度对比 WebGL 与 WebGPU，分析性能差异、浏览器支持现状、迁移成本与生态成熟度，了解浏览器 3D 图形的发展方向。
WebGL 在 2011 年诞生后，让 3D 图形终于来到了浏览器。从此，开发者无需插件就能在网页上渲染复杂的三维场景。然而，WebGL 本质是对二十年前 OpenGL 的直接暴露，随着现代 GPU 架构的演进（特别是 Vulkan、Metal、DirectX 12 的出现），WebGL 的设计开始显示老化迹象：提交开销大、并行性差、特性不足。WebGPU 应运而生，它设计用来抽象现代图形 API 的共同特性，既兼容高性能后端（Vulkan/Metal/DX12），又保留了足够的灵活性。本教程深度对标两者，帮助开发者理解性能差异、浏览器支持现状、以及迁移路径。
WebGL 的起源与局限
WebGL 1.0（2011）基于 OpenGL ES 2.0，一个为移动设备设计的精简 OpenGL。它带来了硬件加速 3D 的梦想，但设计仓促、暴露了太多底层细节。每一次绘制调用（draw call）都有相当的 CPU 开销。
WebGL 1 的典型流程：创建 Shader Program → 绑定 Uniforms、Attributes → 绑定 Texture、Framebuffer → 一系列 glXxx() 调用 → drawArrays()。这个流程是同步的，CPU 在等待 GPU，GPU 在等待 CPU，效率低下。
WebGL 2（2015）基于 OpenGL ES 3.0，加入了 Instancing、Transform Feedback、Sampler Objects 等，性能提升不少。但核心架构仍是"一个大状态机"——全局状态积累，一个错误的绑定会影响之后的所有操作。
此外，WebGL 缺少现代 GPU 的关键特性：Compute Shader、Bindless Texture、Variable Rate Shading 等。
现代 GPU 架构与图形 API 演进
OpenGL 设计年代（1992），GPU 非常简单，性能瓶颈在 API 提交。但如今的 GPU 已是复杂的多核系统，OpenGL 的"全局状态机"反而成了枷锁。
Vulkan（2016）、Metal（2014）、DirectX 12（2015）是新一代图形 API。它们的共同特点：显式状态管理、多线程提交、显式内存管理、Pipeline Objects。
WebGPU 的设计哲学就是对标这三大 API 的共性，抽象出浏览器能安全暴露的子集。
WebGPU 核心特性与性能提升
Pipeline Objects：WebGPU 将 Shader、混合模式、深度测试、光栅化参数打包成一个 Pipeline。编译和验证只做一次，后续使用只需一条指令。与 WebGL 每次 draw 都可能触发编译不同，这大幅降低驱动开销。
Bindless 与绑定组：WebGPU 用 BindGroup 和 BindGroupLayout 管理所有资源。一个 BindGroup 可以包含数百个资源，一次设置整个组，而不是逐个绑定。减少 API 调用，也减少驱动验证。
Compute Shader：这是 WebGPU 相比 WebGL 最大的飞跃。Compute Shader 用来做通用并行计算，不限于图形管线。可以并行处理数百万个数据元素。
显式同步：WebGPU 的 CommandBuffer、Queue、Fence 让开发者精确控制 GPU 同步点。避免了 WebGL 中"glFinish() 阻塞整个管线"的粗暴做法。
性能对比：WebGL 2 vs WebGPU
实际测试数据（各家基准测试不同，仅供参考）：
• 简单 3D 场景：性能基本相同（60 FPS on both）。WebGL 2 已足够。\n• 中等复杂度：WebGPU 快 20-50%，主要因为降低了驱动开销。\n• 高度状态切换：WebGPU 快 2-3 倍，例如在不同材质之间频繁切换。\n• Compute Shader 密集计算：WebGPU 快 5-10 倍。\n• 内存绑定密集场景：WebGPU 更高效。
总的来说，WebGPU 不是万能的性能魔棒，而是在特定场景有显著优势。对于 UI 3D 装饰、简单地形渲染，两者基本无差别。
Three.js、Babylon.js 与 Cesium 的现状
Three.js 是最流行的 3D 库。官方正在开发 WebGPURenderer，已有可用版本但功能不完全。WebGL 后端仍是主流，会继续维护。
Babylon.js 是微软维护的库，在 WebGPU 支持上领先。Babylon.js 4.1+（2021）就有完整的 WebGPU 后端，与 WebGL 后端功能对等。
Cesium.js 是地理信息系统（GIS）3D 库。官方考虑 WebGPU 迁移，但由于应用已很稳定且用户群相对小众，暂无紧迫时间表。
中间件的策略是：保持 WebGL 后端稳定可靠，在 WebGPU 后端足够成熟前不鼓励迁移。
WebGPU 浏览器支持现状
Chrome / Edge（Chromium 113+）：WebGPU 已默认启用（2023 年 4 月）。这是最大的平台，覆盖 70% 以上桌面浏览器用户。性能最优化。
Firefox：正在开发，暂未默认启用。需要用户手动开启；支持程度不如 Chrome。
Safari（iOS 16.4+）：只在 Safari Technology Preview（开发者版）中可用。生产 Safari 用户无法使用 WebGPU。这是最大的兼容性障碍。
结论：2026 年，WebGPU 在 Chrome/Edge 上成熟可用，但 iOS Safari 缺失导致跨平台应用必须保留 WebGL 后备。
迁移成本与生态成熟度
API 差异大。WebGL 的 API 是 C-style，而 WebGPU 是 JavaScript-first。代码完全重写，不能直接端口。
中间件已支持。Three.js、Babylon.js 的双后端设计让用户无需改业务代码。这是迁移的最优方式。
工具链成熟度参差。WebGL 的着色器工具经过十年打磨；WebGPU 用 WGSL 是新语言，IDE 支持、编译器成熟度仍在追赶。
开源库生态。WebGL 的库数量（800+）远超 WebGPU（不到 50）。WebGPU 的库仍在快速增长。
何时选择 WebGPU，何时坚守 WebGL
选 WebGPU 如果：需要 Compute Shader；跨平台兼容性不是问题；愿意尝鲜并接受 API 变化风险。
坚守 WebGL 如果：需要支持 Safari iOS 用户；已有成熟的 WebGL 项目；目标是快速上线。
最佳实践：用 Three.js 或 Babylon.js，编写一次代码，让框架在运行时自动选择后端。
常见问题
现在是否应该迁移到 WebGPU？
短期内不必。WebGL 2 依然很强大，适合中等复杂度的场景（3D 产品展示、地图、游戏）。只有当需要大规模计算（点云处理、GPU 粒子系统数百万级）或需要最新 GPU 特性（compute shader、bindless）时，才值得迁移。而且 WebGPU 浏览器支持还在完善，跨平台兼容性仍需时间。建议关注，但不用急。
WebGPU 的计算能力比 WebGL 强多少？
Compute Shader 是 WebGPU 的杀手锏。在粒子系统、流体模拟、路径追踪等大规模计算中，Compute Shader 可以快 5-10 倍。WebGL 虽然可以用 Framebuffer 对象实现计算，但效率低、代码复杂。对于需要高吞吐的科学计算或数据处理，WebGPU 是游戏规则改变者。但对于普通 3D 渲染，两者的帧率差异不大（都能跑 60 FPS）。
三大图形框架（Three.js、Babylon.js、Cesium）会支持 WebGPU 吗？
已经在支持了。Babylon.js 4.1+ 就有 WebGPU 后端；Three.js 的 WebGPURenderer 也在活跃开发；Cesium 在考虑添加。但 WebGPU 后端仍然是新功能，bug 较多、性能调优未完成。大多数生产项目还在用 WebGL 后端。等 WebGPU 标准完全定型、浏览器实现稳定了（可能还需 1-2 年），才会大规模切换。
老项目的 WebGL 代码会失效吗？
不会。WebGL 1 和 2 是稳定的 W3C 标准，浏览器会长期支持。但新硬件（例如新款 GPU）可能只在 WebGPU 中充分发挥潜能。所以更好的方案是：在框架层（Three.js 等）暴露 WebGL 和 WebGPU 两种后端，让用户选择。应用代码不变，框架在下层切换。
做浏览器 3D 游戏用 WebGL 还是 WebGPU？
现阶段用 WebGL（via Three.js、Babylon.js 等成熟框架）。WebGPU 虽然性能更好，但浏览器支持（Safari 还在 Tech Preview）、中间件成熟度、开发者生态都还不足。小型 2D 游戏或简单 3D 可以尝试 WebGPU；中等以上复杂度的游戏目前还是 WebGL 更稳妥。等 1-2 年 WebGPU 成熟后，新项目会倾向 WebGPU。