配了三年 WebGL，今天才发现它的浏览器正在被框架集体抛弃——WebGPU 把这件事彻底翻了

Three.js 的 WebGLRenderer 写了八年，换个渲染器只要改两行。但没人动，因为换过去会坏。

这个现状在 2026 年终于被彻底翻了——不是 WebGPU 突然变牛了，是 Three.js 在背后把桥接层悄悄填平了。

三件事把「要不要换 WebGPU」的决策焦虑彻底灭了

第一件事：r171（2025 年 9 月）WebGPURenderer 正式达到生产级。只要把 THREE.WebGLRenderer 换成 THREE.WebGPURenderer，加一行 await renderer.init()，Three.js 自动判断用户浏览器支持不支持，不支持就 fallback 到 WebGL 2。两行代码，不用判断浏览器，不用 polyfill。

第二件事：着色器终于不用写两套了。手写 GLSL 的 Custom ShaderMaterial 在 WebGPURenderer 里直接不跑，这是最大的坑。Three.js 的答案叫 TSL（Three.js Shading Language），用节点语法写一遍，自动编译成 WGSL（WebGPU 用）或 GLSL（WebGL 用），两套后端同一个源码。

第三件事：Safari 26 把最后一块缺口填了。2026 年 1 月 WebGPU Baseline 之后，Chrome/Firefox/Safari/Edge 四大浏览器全部稳定，默认开启，全球覆盖率约 82%。

换了之后会踩的三个坑

坑一是 KTX2 压缩纹理。GLB 导出的带纹理模型在 WebGPU 下会黑掉，没有报错，只有一个黑模型。原因是 KTX2Loader.detectSupport(renderer) 必须在 renderer.init() 之后调用，不能在之前。这是论坛里报告最多的 bug，90% 是因为时序写反了。

坑二是 VideoTexture。WebGLRenderer 帮你隐式绑定的视频纹理，WebGPURenderer 不会自动做，要显式用 THREE.TextureNode 包一层。

坑三是 EffectComposer 后处理。旧教程里的后处理管线在 WebGPURenderer 下静默失效，Three.js r183 引入了 RenderPipeline 节点化方案替代。

// 正确顺序
const renderer = new THREE.WebGPURenderer({ antialias: true });
await renderer.init(); // 必须在这里之后
const ktx2Loader = new KTX2Loader()
  .setTranscoderPath('/basis/')
  .detectSupport(renderer); // 在 init() 之后

现在要不要换

如果你的场景 Draw Call 数量高、有大粒子系统、有 ML 推理需求，WebGPU 的 CPU 开销降低和 GPU 并行是真实收益。如果就是展示一个产品模型，WebGL 再撑几年也没问题。

Three.js 的选型建议是：新项目直接 WebGPURenderer 起步，老项目先审计 Custom ShaderMaterial 的数量再决定。GLSL 手写量大的话，迁移成本不低。

框架集体切过去这件事本身就是一个信号——WebGL 的浏览器覆盖率再高，它也是一个正在被主流生态系统性替换掉的技术。