WebGPU 真的在 Three.js 社区炸开是 2024 年下半年之后的事。你身边如果有人在群里晒那种几百万粒子在浏览器里跑到 60 帧的银河或者一个不用加载任何贴图、纯粹靠算法生成的海面那基本就是 WebGPU TSL 的作品。我差不多半年里把主力渲染器从 WebGLRenderer 切到了 WebGPURenderer再回头去看三年前写的 GLSL 字符串着色器说实话有一种终于不用拧螺丝的感觉。这篇就来拆一拆社区里转发量最高的 10 个方向讲清楚每个演示到底是怎么做出来的、用到了哪些 TSL 节点、以及踩坑时最值得注意的几个点。不论你是做可视化大屏、3D 产品配置器还是游戏前场景这几个案例基本已经覆盖了 WebGPU 时代最常见的玩法。**先说结论这次爆发不是换了个 API 名字而是开发心智和运行模型同时变了。**WebGL 时代的痛点不是慢不慢而是写自定义着色器太反人类——你要把 GLSL 当作字符串拼进 ShaderMaterial改几个字就得热重载出了错报错信息还是另一套编译器的。TSLThree.js Shading Language把这些全部打散成可以组合的节点你用 JavaScript 函数一样去写 shader而 WebGPU 又把 GPU 计算能力彻底开放粒子、布料、流体这种以前 CPU 算不动、WebGL 又算不对的东西现在都可以直接搬上 GPU。当这两个东西碰在一起整个社区突然发现原来浏览器端表现力还能再上一个大台阶。1. 这次社区爆发背后其实是两个老问题的答案很多人以为 WebGPU 只是比 WebGL 快一点真不是。我从 r155 左右开始追 Three.js 的 WebGPURenderer一路用到现在最大的体感是**这个渲染器从底层设计上就假设你在跟 GPU 打交道而不是在跟 OpenGL 的遗留状态机打交道。**WebGL 里面有大量隐式状态绑定纹理、切换 VAO、设置 blend 模式任何一个环节忘了恢复默认值就会出现从上个物体那儿继承过来的鬼影。1.1 WebGPU 解决了 WebGL 的天花板WebGL 的架构是 2011 年前后定下来的那时候大家还在讨论手机 GPU 能不能跑 3D 游戏所以 API 都是围绕固定管线 可编程片段的混合去设计。但今天你随便打开一个可视化大屏要的不是三角形而是几万几十万个实例、一张大纹理、或者要在 GPU 里跑一段物理模拟。WebGPU 带来的关键变化有三个第一是显存管理和资源隔离比 WebGL 干净得多。WebGPU 有 GPUDevice、GPUBuffer、GPUTexture 这些东西创建、分配、释放都有明确语义不再像 WebGL 那样一个 buffer 挂了驱动级别还常见各种隐式依赖。第二是Compute Shader这个太关键了。WebGL 里你想做粒子位置更新要么用 CPU 循环算完再传到 GPU要么靠 vertex shader 里做一些投机取巧的做法。WebGPU 直接支持通用计算位置更新、碰撞检测、布料约束、流体积压都能在 GPU 内部完成CPU 只需要发一个 dispatch。第三是更高效的 draw call 管理比如 render bundle、动态 uniform 偏移等机制让引擎可以批量提交渲染命令这在大量小物体的时候提升非常明显。1.2 TSL 把着色器变成了像 JS 一样的可组合积木我印象里 TSL 最初在 Three.js 里是 node editor 的一个概念后来被抽出来成了一个独立的语言层。它看起来就像一个用 JS 写 shader的 DSL。举个例子以前要写个随时间变化的透明度你得写float alpha 0.5 0.5 * sin(uTime);然后你还得想着 uniform 怎么传、字符串怎么拼接。用 TSL直接这样import { sin, time } from three/tsl; const alpha 0.5.add(0.5.mul(sin(time())));看着就是 JS 语法但它背后会生成对应的着色器源码。这样最大的好处是可以像封装 JS 函数一样封装着色器片段。你把一个水波、一个扰动、一个噪声打包成函数在这个材质里用、在那个特效里用不用再复制粘贴字符串也不怕拼错花括号。最要命的是报错信息现在直接定位到节点不像以前给你一段编译后的 GLSL 让你猜是哪个字符串出了问题。1.3 现在该不该上车如果你做的项目是官网 3D 展示 一个粒子特效 一个轮播场景说实话切不切 WebGPU 影响不大。但如果你已经在做粒子数量过万就开始掉帧想实现水面、布料、流体这些有物理或数学模拟效果需要自定义复杂着色器但不想维护 GLSL 字符串场景实例数量多比如机房里的机柜、城市里的楼宇那真的建议现在就开始动手。WebGPU 在 Chrome/Edge 默认已经开启Safari 也有对应支持路径用户群体覆盖面已经够大了。Three.js 官方也已经在逐步把 WebGPU 相关 API 稳定化现在入局不算早也不算太晚等完全稳定了你再学又得吃一遍别人吃过的转换苦。2. 视觉冲击派5 个被转疯的演示这一组案例是社区转发里最常见的特点就是一个词一眼爆炸。它们不一定在业务里直接可用但传播效果极好也最能体现 TSL 的威力——因为光影、颜色、动态都是按程序算出来的根本不依赖美术给一堆贴图。2.1 案例 1百万粒子星系这个案例几乎是每人必跑的。百万粒子以前我拿 WebGL CPU 更新 position8000 个粒子就把主线程占满了。换成 WebGPU TSL 之后位置更新全部在 GPU 里做主线程只是每帧触发 dispatch。核心思路是把粒子的位置、速度、随机种子放在存储缓冲区里用 compute shader 去更新然后在 vertex 阶段读取出来再设置大小和颜色。代码结构大概是这种样子import { storageBuffer, positionLocal, float, uniform } from three/tsl; // 每帧跑一个 GPU compute更新 posBuffer const updatePos Fn(() { const pos storageBuffer(particleBuffer, vec3, count).toVar(); const vel storageBuffer(velocityBuffer, vec3, count).toVar(); const time uniform(timeRef).toVar(); pos.addAssign(vel.mul(delta)); vel.addAssign(gravity.mul(delta)); // ... 按星系形状做旋转把 pos 绕中心点转 })().compute(count);很多抄这个 demo 的人都会犯一个错直接在 Points 的 vertex shader 里写一堆旋转公式而没意识到真正要做的分帧计算。星系、星云这种效果位置天然不是你每帧在顶点里能临时算出来的它需要一个累积状态。WebGPU 的 storage buffer 就是干这个的。实际调试时我建议先从 5000 个粒子跑起逻辑对了再往上叠省的百万粒子一出错都不知道从哪看起。另一个坑是 Points 的frustumCulled。粒子分布在很大空间里如果 cull 逻辑把整体包围盒算错就会出现镜头一转粒子全没了。我一般直接关掉剔除或者把包围盒手动设成一个足够大的盒子。当然粒子数量到百万级别之后别再用 Thousands of meshes 那套逻辑随时都要记住 GPU 才是你的朋友。2.2 案例 2海岛波浪水面水面是 WebGPU 社区里争议最小、效果最好的一个方向。很多 Demo 会直接在一层平面网格上写一个噪声函数叠加正弦波再用 dFdx/dFdy 近似法线最后把天光和环境反射颜色 mix 到一起。因为整个效果只需要一个 PlaneGeometry加上一个MeshStandardNodeMaterial就能出片。TSL 里水面核心大致这么写import { sin, time, uv, positionLocal, vec3, mix } from three/tsl; const point positionLocal.xy; const wave sin(point.x.mul(3.0).add(time())) .mul(0.15) .add(sin(point.y.mul(2.5).sub(time()).add(wave2))); // 把波动应用到顶点高度 positionLocal.y.addAssign(wave);这样做的好处是 GPU 全程参与顶点不回流到 CPU。你在社区看到的波光粼粼效果其实不是三角形多而是法线变化足够细腻。水面真实感很大程度靠 normal 的扰动顶点只要够密到能表现大波就好微小的波光完全可以用法线贴图或者 TSL 里程序生成的 normal 去解决。实操的时候建议把水面网格分辨率控制在 128x128 左右太高了不但顶点计算量大而且 aliasing 反而更明显。如果你要加倒影最简单的做法是往材质里塞一张环境贴图可以用案例 7 的正方体摄像机实时生成六面体会比反射平面省事很多。最后配合一个雾效基本就是社区里最火的那种海岛镜头了。2.3 案例 3GPU 毛球 / 草地毛发、草地这类东西在 WebGL 时代几乎不敢碰因为每根毛都是一条线或一个面片几千根就能拖垮 CPU 的批次数量。但 WebGPU TSL 让用粒子去表现毛变成现实粒子本身是细长的 billboard沿着法线方向拉伸再加点随机扰动和风场。毛发的核心其实在材质阶段TSL 里可以做单根毛的颜色渐变、随机采样噪声分布、以及边缘透光效果。比如import { normalWorld, positionWorld, uv, mix, color } from three/tsl; const randomOffset hash(attribute(seed).toVec3()).toVar(); const normalizedDist uv().y; // 0 在根部1 在顶尖 material.colorNode mix(color(#4a7c59), color(#d8f0c0), normalizedDist); material.positionNode normalWorld.normalize() .add(randomOffset) .mul(length(attribute(lengthFactor)));这里有个很关键的 TSL 窍门不要在你的 geometry 上真的写几百万个顶点用少量带 seed 的 instance 属性去控制生成方向。一个毛球用一个低模球体当宿体然后在片段阶段画小细条或者用片状粒子去模拟效率高很多。如果你做草地场景记得风向要统一成一个 low frequency 的噪声 campo而不是每根草瞎抖。否则在流媒体上看着会像地震 帕金森而不是风吹草动。2.4 案例 4TSL 能量火焰护盾这是游戏向和特效向都爱转的一个方向看起来像是角色身上套了个发光的能量罩。在 WebGPU 里实现起来核心就三行一个噪声做扭曲、一个 smoothstep 做透明、一个 mix 做颜色渐变。const distortion noise(uv().add(time())).mul(vec2(0.2, 0.1)); const base uv().add(distortion); const alpha smoothstep(0.2, 0.5, noise(base));很多人第一眼看到这种东西会觉得很高深其实原理特别简单**把噪声节点当作 uv 偏移。**这个技巧在 shader 界叫 domain warping所有扭曲燃烧岩浆流动云朵翻滚效果都是它的变体。TSL 里提供了一堆噪声节点省得你自己写 GLSL 的 Simplex 噪声。我强烈建议如果你想学 TSL先把这个效果做出来试试它把节点组合的心智模型体验得特别彻底。火焰护盾还可以叠加菲涅尔边缘光。用normalWorld().dot(viewDirection())算一个边缘衰减放到 alpha 里就能做出只亮在轮廓一圈的能量罩非常出片。2.5 案例 5后处理辉光 色散很多演示最后一帧的电影感其实来自后期。Three.js 官方后处理库 EffectComposer 现在也已经兼容 WebGPURenderer而 TSL 让自定义后处理变成一张全屏四边形 一个材质就能解决的事。最常被转的后期是Bloom辉光 Chromatic Aberration色散import { pass, uv, texture, add, mix } from three/tsl; const color texture(colorBuffer, uv()); const blur texture(bloomBuffer, uv()); const finalColor color.add(blur.mul(1.5)); // 色散分别让 R/G/B 通道偏移一点点 const offset 0.002; const ca vec3( texture(colorBuffer, uv().add(offset)).r, texture(colorBuffer, uv()).g, texture(colorBuffer, uv().sub(offset)).b );我一开始也担心 WebGPU 下后期会特别麻烦实际一跑发现反而简单了——因为很多状态不需要你手动设像素格式、绑定组这些都交给引擎。真正要注意的是不要在 Bloom 采样的时候把 alpha 通道丢掉很多后处理的坑都出在 alpha blend 上。一般 Bloom 采样链最好保存为半浮点纹理避免高亮区被 clamp 成一个纯白团。后期做多了你会慢慢意识到WebGPU 时代里每个特效其实都是一种资源编排。TSL 负责描述怎么算渲染管线负责什么时候算这两者配合好了效果上限比 WebGL 时代高不少。3. 业务落地派这些演示也不是只能当炫技第二组案例在社区里同样火但是方向截然不同。它们解决的是可视化、数据大屏、产品展示这类真实需求。很多人搜three.js 机房vue3 three.js typescript 机房雨雪雾怎么实现的时候其实已经是在找这类方案了。3.1 案例 6机房 / 数据中心三维可视化机房可视化是我这一年看下来 WebGPU 落地最实在的场景也是中文社区里搜索热度很高的方向。它的本质是大量 InstancedMesh机柜、服务器、指示灯 少量动态效果风扇旋转、管线流动、温度热力图。这种场景以前最头疼的是几万个指示灯、几百个机柜每个都做交互、都有状态变化一帧一帧刷新 CPU 根本忙不过来。用 WebGPU TSL 之后机柜本体可以全走 instancing每个 instance 的运行状态用一个 attribute 存进去颜色直接根据状态在材质里映射import { instancedMesh } from ./models.js; const mesh instancedMesh(rackGeometry, rackMaterial, count); // ... 通过 setMatrixAt 设置位置旋转 // TSL 材质内根据 state attr 映射颜色 material.colorNode mix(color(#374151), color(#ef4444), stateAttr);配合 Vue3 TypeScript 做工程整合时比较重要的点是把渲染器生命周期和组件生命周期对齐。我的经验是**WebGPURenderer 实例放在组件模块级或者用一个单例管理而不是每个组件都 new 一个。**GPUDevice 创建的代价并不低你一个页面多个组件都创建 device内存涨得飞快。组件销毁的时候要记得释放纹理、buffer 这些显存资源不然切路由几次之后 GPU 内存就爆了。温度热力图那种机柜从绿到红渐变的效果在 TSL 里就是一个smoothstep映射的事不需要每帧传大数组只需要传一个uniform温度区间。这样不仅效果好看代码也意外地短。3.2 案例 7正方体摄像机镜像反射这是很多搜three.js 正方体摄像机效果的人实际在找的功能。正方体摄像机CubeCamera就是拿六个方向的透视相机去渲染一张立方体贴图然后给镜面物体采样。网上大量关于金属球、镜面地板的 demo核心都没逃过这个。加上 WebGPU 之后这个流程更顺了因为 CubeTexture 在 GPU 里就是一张纹理数组采样方式更自然。TSL 里用立方体贴图的写法import { cubeTexture, positionWorld, reflect } from three/tsl; const env cubeTexture(envCubeTexture); const reflDir normalize(positionWorld.sub(cameraPosition)).reflect(normalWorld); const reflectedColor env.sample(reflDir);做这个效果最需要留意的坑是Cubemap 的分辨率和更新频率要分开控制。反射物不需要每一帧都重新渲染 6 个面一般每 3 到 5 帧更新一次就够了。如果机子性能不行还可以先把 scene 的某些静态层缓存成 static cubemap。我见过很多 demo 明明主要物体只有一个小球镜面结果每帧渲染 6 次整个场景直接把帧率干到十几。另外全屏水面的镜面反射其实也可以用 CubeCamera 偷懒但水体这种大面积反射如果完全依赖 cubemap细节会显得糊。要更好看可以把 cubemap 的 mipmap 开大一点或者配合粗糙度 roughness 去模糊反射采样。3.3 案例 8场景共享与序列化一个被忽略但超实用的方向社区里有个热搜词叫 three.js 共享 序列化很对我胃口。其实 WebGPU 时代场景资源的管理方式变了很多因为显卡不再接受你把一堆 CPU 对象塞给我这种间接写法。共享意味着你可以在一个 GPUDevice 里创建一个大 Buffer然后在多个渲染管线里同时引用序列化则意味着你要考虑把 Three.js 场景结构存下来之后怎么在 WebGPU 环境里恢复。TSL 节点的好处在这里体现得特别深——因为节点本身就是数据。你可以把节点材质序列化成 JSON 对象从node.toJSON()拿结构然后在另一个页面里用nodeMaterialLoader重建。这不再是字符串级别的拼接而是一棵可遍历的节点树。我实际踩过的坑是GPU 资源不能直接序列化。纹理上传之后有个 GPU 内部的 handle你把这个 handle 写成 JSON 存下来重启页面它根本不存在。正确姿势是序列化source比如图片地址、ArrayBuffer 的 URL而不是序列化 GPU 采样器句柄。共享同理同一张纹理可以被多个材质引用但你要保证texture.needUpdate的时机是一致的否则会出现这个场景正常、那个场景糊了的灵异现象。3.4 案例 9InstancedMesh 让森林、军队、城市批量动起来这个案例直接面向要很多很多物体动起来的场景。例如在一个城市可视化里几百栋楼一起亮灯熄灯一个公园里上千棵树被风吹摇摆。传统写法是每帧循环遍历所有实例对象去调matrix.setPosition然后更新 matrix两三百个还能撑住四五千个就开始掉帧了。WebGPU TSL 的做法是把变化的量变成顶点属性或 storage buffer然后在 shader 里算矩阵const instanceOffset attribute(instanceOffset); const wind sin(time().add(instanceOffset).mul(0.2)); // 在顶点里把 world matrix 的位置偏移做掉 const localPos positionLocal; localPos.x.addAssign(wind.mul(0.05));这里有一个很实用的建议**别把每个树的旋转矩阵都传进 shader那样太浪费带宽。**你可以让实例的世界矩阵保持不变把动态变化量用一个 vec3 属性传进去叠加在矩阵变换之后的位置上。这样场景里几百上千个实例变化量只有三个 float既省显存又省指令。做这类效果时我最大的感受是TSL 给了你什么放在 CPU、什么丢给 GPU的自由度。以前 CPU 循环改矩阵改到哭现在把 change amount 设置好shader 里自动算你能明显感觉到原来性能是这么省出来的。3.5 案例 10GPU 布料社区转发里的常青款从经典的那块飘动的旗子开始布料的 demo 就没冷过场。以前在 WebGL 里做布料约束极其痛苦你要么在 JS 里算几百上千次约束迭代要么干脆不做让布料看起来像块湿面粉。WebGPU 的 compute shader 则是为这类计算而生的一次性把粒子的速度和位置扔到缓冲区里然后在 GPU 里做约束迭代。TSL 写布料约束大概是这种形状const compute Fn(() { const idx uniform(instanceIndex).toVar(); const pos storageBuffer(posBuffer, vec3, particleCount); const newPos storageBuffer(newPosBuffer, vec3, particleCount); // 约束迭代限制粒子间距 for (let i 0; i ITERATIONS; i) { // 读取邻居节点按弹簧约束修正 newPos } })().compute(particleCount);在实操里我发现一个容易坑人的点**GPU compute 的并发写问题。**如果你在 compute shader 里让多个线程同写一个 buffer 位置结果会不确定。布料约束里很多求解要处理粒子两两之间的关系最简单的做法是先考察上半三角再对称写回或者分多次 dispatch每次只处理一个方向的约束。很多拿来即用的教训就是不要试图在一个 dispatch 里同时做读-改-写你的结果大概率是花的。做布料模拟时记得把 cloth 的顶点法线也要从相邻粒子位置推导出来否则渲染出来没有光影层次会非常难看。TSL 可以直接在顶点里做这些推导这比每帧传法线回 CPU 再传回 GPU 高效得多。4. 从零迁移把现在项目换到 WebGPU TSL 的最短路径看完了 10 个案例你大概率会想那我自己手上那个项目怎么切这里给一条我亲测最短的迁移路径。不用把整个项目推翻也不需要你先去把 WebGPU 官方规范啃一遍。4.1 最小切换new WebGPURenderer()最核心的一步是把渲染器替换掉。 r160 之后的 Three.js 写法类似这样import { WebGPURenderer } from three/webgpu; const renderer new WebGPURenderer({ antialias: true }); await renderer.init(); renderer.setSize(window.innerWidth, window.innerHeight); document.body.appendChild(renderer.domElement);注意WebGPURenderer 的初始化是异步的必须await renderer.init()后再开始渲染否则 canvas 会黑一段。在这里我开始时踩过很蠢的坑忘了renderAsync以为和 WebGL 一样直接render就行结果是画面一直不出现错误还藏在 Promise 里不告诉你。4.2 第一个 TSL 材质长什么样替换完渲染器你原来的 MeshStandardMaterial、MeshBasicMaterial 大多还能用因为 Three.js 会自动把它们转成节点材质。但如果你想开始用 TSL 的威力就写一个自定义材质import { MeshBasicNodeMaterial } from three/webgpu; import { color, uv, mix } from three/tsl; const mat new MeshBasicNodeMaterial(); mat.colorNode mix(color(#00aaff), color(#ff00ff), uv().x); const mesh new Mesh(geometry, mat);就这几行一个从蓝到紫渐变的效果就出来了。理解这个模式之后你会发现你可以把任何 GLSL 里的计算搬进colorNode、positionNode、normalNode。比如把positionNode改了顶点就开始动。这正是案例 2 水面的基础。4.3 在 Vue3 TypeScript 里组织生命周期如果你习惯 vue3 three.js typescript 这种组合那么重点不是语法而是生命周期对接。我推荐的模式是在onMounted里初始化渲染器、场景、相机用renderer.setAnimationLoop而不是requestAnimationFrame因为 WebGPU 推荐这种循环在onUnmounted里销毁渲染器和所有 GPU 资源。销毁的部分尤其重要。WebGPU 不像是 WebGL 那样交给浏览器慢慢回收你需要显式renderer.dispose()并且注意释放自己创建的 Buffer 和 Texture。如果有 Worker 线程在跑也要一并 terminate。4.4 兼容性兜底你还是要留一条 WebGL 的路WebGPU 还没法在所有设备上保证 100% 可用有些还是旧版驱动/旧系统的环境。我个人的处理是做一个检测函数如果navigator.gpu不存在就自动回退到 WebGLRenderer。TSL 的材质并不依赖 WebGPU你写的 NodeMaterial 理论上也能跑在 WebGL 的渲染路径上只是 GPU compute 这类能力不能用。这种降级方案对于业务项目特别重要不然你把整个大屏切过去客户电脑不行你连救回来的机会都没有。判断逻辑一般长这样if (navigator.gpu) { renderer new WebGPURenderer(); } else { renderer new WebGLRenderer(); }然后你后续代码都用同一个抽象的 renderer 变量。如果碰上个别 compute 效果降级无法运行就先判断一下能力再决定要不要展示高级特效。5. 我踩过的坑常见问题排查实录这一章最值钱。我从 r160 到 r167 一路升到 WebGPU中间踩的坑足够写两篇长文了。我挑了五个出现频率最高的问题做成一个速查表你直接对照排查。现象可能原因解决思路切到 WebGPU 后一片黑没有 await renderer.init() 或没有用 renderAsync先 await 初始化再启动 animation loopTSL 材质报错但 WebGL 正常节点 API 版本不一致用了旧版 three/nodes 的导入路径换到three/tsl和three/webgpu路径锁定版本粒子一多帧率反而暴跌仍然在 CPU 更新 BufferAttribute 并每帧 upload切换到 storage buffer compute 更新反射效果糊成一片Cubemap 分辨率太低或每帧渲染六面太多降更新频率提高纹理分辨率开 mipmap纹理上传很慢、内存暴涨每次 setTexture 都触发整体 re-upload显式管理 texture 生命周期能复用就复用5.1 切到 WebGPU 后一片黑这个现象最常见。WebGPURenderer 不是同步初始化的它需要获取设备、创建交换链这全是异步操作。所以await renderer.init()这步必不可少。即使是随后每次渲染早期版本你还得用renderer.renderAsync(scene, camera)等 render 完成再继续下一帧。后期版本逐渐兼容了同步调用但我个人为了保险还是做了渲染器版本的 feature detect。另外一个容易被忽略的**显卡不支持 compute shader 或者 swapchain 格式不支持时init 会 resolve 失败。**尽量 try/catch 包住打出错误原因。5.2 TSL 和传统 ShaderMaterial 混用报错你可以在一个场景里同时用 MeshStandardMaterial 和 TSL 的 MeshStandardNodeMaterial这没问题。但如果你把 TSL 节点塞进传统 ShaderMaterial 的uniforms字段里或者反过来在一个 NodeMaterial 里引用一个旧版 UBO大概率会出毛病。原因是两套资源绑定机制不一样。我的建议是不要混用。要写自定义效果就统一用 NodeMaterial要快速搭建就用原生内置材质中间没有过渡方案。而且你要特别留意你安装的三件套版本。很多人搜教程时看到的three/nodes导入路径现在已经被three/tsl取代了如果你拿两个不同版本的项目代码混拼报错信息会非常玄学。5.3 粒子一多帧率反而跌如果你已经上了 WebGPU粒子却还是很卡九成原因是你的代码其实还停留在CPU 算GPU 画的阶段。WebGPU 的架构优势只有在数据不离开 GPU 的时候才能体现。你画 100 万粒子就得让那 100 万个粒子的状态一直待在 GPU storage buffer 里每帧 compute 更新然后 vertex 里直接读。如果每帧从 CPU 往 GPU 拷贝一个 100 万粒子的数组光传输就要几十毫秒帧率当然崩。另外一个隐蔽问题是PointsMaterial默认按屏幕像素画点WebGPU 下如果粒子数多到遮住了所有片元填充率也会成为瓶颈。可以考虑用矩形片元代替点或者降低点尺寸。5.4 CubeCamera 反射在 WebGPU 下表现不佳很多做镜面反射的都来问我为什么贴了 cubemap 之后模糊怪怪的。一般就两种情况cubemap 分辨率不够或者采样方向算错。TSL 里reflect()函数传入的应该是viewDir但新手很容易写成positionWorld。反射方向一错画面自然就花。再就是 CubeCamera 更新频率过高每帧 6 面渲染顶不住。对于反射物面积大但占屏比例小的场景每 4 帧一更新肉眼基本看不出差别。5.5 纹理上传慢、内存暴涨最后聊一下纹理。WebGPU 的资源上传是异步的但你创建纹理之后立即拿去渲染容易遇到上一帧还没传完这一帧已经读取了的情况表现为模糊或者闪烁。Three.js 帮你做了不少同步但纹理较大、分辨率较高的时候还是会有怪问题。最稳妥的做法是在进入正式渲染循环前先await renderer.compileAsync(scene, camera)或者主动做一次静态场景渲染让纹理、buffer 先传到 GPU。很多切换页面之后第一次渲染特别卡的体验就是这么治好的。至于内存暴涨多半是纹理或者 buffer 在使用完之后没有 disposeGPU 资源不会自动 GC。尤其在做动态加载大场景的时候每加载一个模块就 new 一堆资源切场景只清理了 DOMGPU 侧的内存全留在那儿了。所以你在给一个页面做资源管理的时候一定要把 dispose 的时机管理好这比优化一两行代码效率高得多。6. 给想跟上这波节奏的人的三条私货十来个案例拆完最后分享一点我的实际感受。第一件事**别急着把项目整体迁移到 WebGPU。**我建议你先在一个无关紧要的模块里试水比如一个粒子特效、一个自定义材质跑通了、性能对比好了再开始全量切。WebGPU 虽然已经可用了但它对资源管理、异步初始化这些要求比 WebGL 严格得多你的项目如果历史包袱重整体切换的阵痛期不会短。第二件事**TSL 材质只要封装得合理它就能像乐高一样到处复用。**我一开始所有节点都写在组件里后来发现同一个水面材质被 8 个场景引用代码改了一处就要同步 8 处简直噩梦。后来我把水波、噪声扰动、风场全拆成函数每个效果变成一个工具函数任何材质需要就直接 import后续维护就是改函数实现一个地方的事。第三件事**多去翻一翻 Three.js 官方示例里 webgpu 文件夹下的 demo。**社区里最火的那些案例大部分原型都是官方示例的变体先把这些跑通再谈创新这是最快的学习路径。我不保证这篇文章里每一行代码都能在你的环境里原样跑通毕竟 Three.js 还在高速迭代API 细节随时可能调整。但里面的思路、坑位和工作流是这半年里我从一个又一个涨红脸的问题里攒出来的。如果你也在迁移路上卡住过看到上面某一条害得你熬夜那这篇拆解就没白写。欢迎在评论区聊聊你是在哪一步卡住的尤其是那些报错信息很多时候不是你蠢只是这波变化实在来得太快了。