three.js 中的WebGPU 有几成熟了？

THREE.WebGPURenderer 是 Three.js 官方新一代渲染器，专门对接 WebGPU API。

一、WebGPURenderer 成熟度总结

能用、适合新项目，但未完全追平 WebGLRenderer；生产可用但有迁移成本与功能缺失，属于「准成熟、未来主力、仍在补全」阶段。

1. 已经成熟、稳定可用的场景

基础标准渲染

Scene / Camera / Mesh / 标准 PBR 材质、光照、GLTF/GLB 加载、轨道控制器、基础几何体、实例化模型、简单动画完全稳定，上层 API 和 WebGL 几乎一致，小模型商品展示、轻量化 3D 预览无坑。

WebGPU 独有能力完全落地

Compute 计算着色器、百万级粒子、GPU 并行模拟、硬件光线追踪、海量实例模型、点云 / 激光雷达大数据渲染，性能碾压 WebGL，这是 WebGPU 核心优势场景。

浏览器兼容性普及

Chrome/Edge/Firefox/Safari 新版全部支持；移动端 iOS17+、新版安卓可用；仅老旧手机、旧 Windows 集成显卡、低版本浏览器缺失 WebGPU，可优雅降级 WebGL。

官方持续主力维护

Three.js 官方把 WebGPURenderer 作为长期路线，每版本持续修复 bug、补齐功能，大量官方示例、文档配套完善。

2. 仍未完全成熟、不适合直接无脑迁移的场景

存量大型 WebGL 老项目（大量自定义 GLSL ShaderMaterial、onBeforeCompile、传统 EffectComposer 后处理）；
依赖大量第三方 3D 插件、老旧性能监控工具（stats-gl）；
目标用户包含大量老旧电脑 / 低端安卓、老旧集成显卡；
大量独立小 Mesh、频繁动态创建销毁物体的场景（首帧编译开销大）。

二、WebGPURenderer 现存核心缺陷与限制（官方文档明确标注）

1. 材质与着色器体系断层（最大迁移痛点）

完全不支持传统 GLSL 材质
- ShaderMaterial、RawShaderMaterial、onBeforeCompile 直接失效，不会自动转译 GLSL（早期版本的自动转译已废弃）Three.js；
- 原有所有自定义 GLSL 着色器必须二选一重构：
  
  ① 使用NodeMaterial + TSL（框架推荐，节点式材质语言）；
  
  ② 使用 RawWGSLMaterial 手写原生 WGSL；
- 大量老项目写的自定义 GLSL 特效、描边、渐变、卡通渲染都需要重写，迁移成本极高。
两套材质体系并行，学习成本翻倍

WebGL 走传统材质，WebGPU 强制 Node/TSL/WGSL，两套语法、两套逻辑，不能共用。

2. 后处理系统完全不兼容传统 EffectComposer

WebGL 旧后处理通道（RenderPass、UnrealBloomPass、SSAO 等）全部无法运行；
WebGPU 只能使用新一代节点后处理（PostProcessing Nodes） ，虽然效果更强、性能更好，但老后处理代码全部作废，大量第三方后处理插件不兼容Three.js；
部分小众后处理效果官方还未完成移植。

3. 性能短板（容易踩坑）

首帧加载极慢（冷启动瓶颈）

首次渲染会批量创建绑定组、编译 WGSL 管线，大量独立 Mesh 场景下，首帧耗时是 WebGL 的 5~10 倍；反复销毁重建物体时 GPU 管线频繁重建，卡顿明显。

大量独立小模型场景 CPU 开销更高

没有实例化、上千个独立 Mesh 时，WebGPU 每帧绑定组切换开销大，CPU 占用反而高于优化成熟的 WebGLRenderer；只有大规模实例化 / 粒子场景才会拉开性能差距。

老旧硬件驱动 BUG 多

Intel 老核显、老旧 AMD/N 卡驱动存在 WGSL 编译崩溃、纹理错乱、GPU 进程闪退，无法通过前端代码修复，只能降级 WebGL。

4. 生态与第三方工具兼容缺失

老性能工具失效：stats-gl 不兼容 WebGPU，只能用官方内置 Inspector 性能面板；
部分辅助工具、扩展、第三方加载器、物理插件存在适配问题；
社区教程、中文资料远少于 WebGL，踩坑后解决方案少。

5. API 异步化带来的开发改动

WebGL 同步渲染 renderer.render()；WebGPU 必须 await renderer.renderAsync()；
渲染器需要手动 await renderer.init() 初始化，异步逻辑侵入渲染循环、加载流程，原有同步渲染代码需要改造；
资源创建、纹理上传存在异步时序坑，容易出现渲染黑屏、模型延迟出现。

6. 部分边缘功能缺失 / 行为不一致

部分老旧几何体、辅助线、Sprite、Points 渲染逻辑和 WebGL 有细微差异；
某些纹理参数、透明混合、深度写入、多重采样抗锯齿在不同浏览器表现不一致；
WebXR VR/AR 适配仍有少量兼容性 bug，不如 WebGL 稳定；
内存自动回收逻辑不如 WebGL 完善，频繁创建销毁资源容易 GPU 内存泄漏，需要手动释放。

三、WebGPU vs WebGL 适用场景选择参考

优先选 WebGPURenderer（利大于弊）的场景：

百万级粒子、流体、GPU 物理模拟、点云 / 超大场景；
需要硬件光线追踪、SSGI 全局光照、实时全局光照；
现代设备为主、追求长期性能、新项目从零开发；
大规模实例化模型、数字孪生、高精度 CAD 预览。

优先选 WebGLRenderer（规避 WebGPU 缺陷）的场景：

存量老项目，大量 GLSL 自定义着色器、传统后处理；
面向下沉低端设备、老旧电脑 / 手机；
轻量化简单 3D 展示、少量模型、追求快速上线零迁移成本；
依赖大量老旧第三方 3D 插件。

四、生产环境落地建议（规避缺陷）

强制做降级判断，不支持 WebGPU 自动切 WebGL：

ini 复制代码

let renderer;
if (await WebGPURenderer.isAvailable()) {
  renderer = new WebGPURenderer({ antialias: true });
  await renderer.init();
} else {
  renderer = new THREE.WebGLRenderer({ antialias: true });
}

新项目直接使用 NodeMaterial 写材质，统一 TSL 节点体系，避免后期重构；
海量小 Mesh 场景全部使用 InstancedMesh 实例化，缓解首帧与 CPU 性能问题；
提前封装 WGSL/TSL 通用材质库，减少重复着色器编写；
避免频繁创建销毁 Mesh、材质、纹理，复用 GPU 资源，减少管线重建开销。

五、未来趋势

WebGL 不会被立刻淘汰，但 WebGPURenderer 是 Three.js 长期唯一迭代主线；

未来几个版本会持续补齐材质、后处理兼容性，缩小功能差距，长期来看 WebGPU 会完全替代 WebGL。