企业官网建设流程全解析

1. 从“2. 3D图形”这个标题说起：为什么它值得单独拎出来讲

看到“2. 3D图形”这个标题，很多人第一反应可能是：这不就是计算机图形学里最基础的一章吗？教科书上从坐标系讲到投影矩阵，从顶点变换讲到光栅化，翻来覆去就那么些东西。但如果你真的动手写过渲染器，或者用Three.js、Unity、Blender做过实际项目，就会发现一个尴尬的事实：能画出三角形和能做出让人愿意多看两眼的3D画面，中间隔着一整条鸿沟。

这个标题里的“2.”其实透露了一个信息——它大概率是某个系列内容中的第二篇，前面应该已经铺垫了基础概念，比如什么是顶点、什么是网格、什么是坐标系。而“3D图形”这四个字，涵盖的范围又极其宽泛：从最底层的GPU管线，到上层的场景组织、材质系统、光照模型，再到性能优化和跨平台适配，每一块都能单独写一本书。

我写这篇东西的出发点很简单：把“3D图形”这个看似人尽皆知的话题，拆成真正能落地的东西。不管你是刚学完线性代数想找个方向练手的学生，还是从后端转过来做可视化、数字孪生、小游戏开发的工程师，或者是做工业仿真、建筑漫游、电商3D展示的技术负责人，这篇文章都会给你一套完整的认知框架和实操路径。

先明确一下范围。这里不打算从“什么是向量”开始讲，那是另一篇文章的事。我们聚焦在：当你已经知道3D图形的基本概念之后，真正动手做一个3D场景时，会遇到哪些绕不开的问题，以及这些问题背后的原理和解决方案。关键词就三个：渲染管线、场景组织、性能与效果平衡。这三个词贯穿了所有3D图形项目的生命周期。

我见过太多项目，前期Demo跑得飞快，一到真实数据量就卡成幻灯片；也见过不少团队，为了追求“电影级画质”把帧率压到20以下，用户点两下就关掉了。这些问题的根源，往往不是某个API用错了，而是对3D图形系统的整体运作方式缺乏系统性的理解。接下来的内容，我会按照一个3D场景从无到有的实际构建顺序来展开，每一块都配上我踩过的坑和验证过的方案。

2. 渲染管线：数据从内存到屏幕的完整旅程

2.1 顶点处理阶段到底在算什么

很多人对渲染管线的理解停留在“顶点着色器处理顶点，片元着色器处理像素”这个层面。这话没错，但太粗了。真正写代码的时候，你需要知道的是：一个顶点从进入GPU到变成屏幕上的颜色，中间经历了哪些坐标空间的变换，每个空间存在的意义是什么。

拿一个最简单的场景举例：你在Blender里建了一个立方体，导出成glTF格式，然后用Three.js加载进来。这个立方体的8个顶点，在模型文件里存的是模型空间坐标，通常以物体自身的中心为原点。当你把它放到场景里，设置position为(3, 0, 0)，这时候顶点需要乘以模型矩阵，变换到世界空间。世界空间是整个场景的统一坐标系，所有物体都在这个空间里定位。

接下来是观察空间。摄像机有位置和朝向，观察矩阵的作用就是把世界空间的坐标转换到以摄像机为原点的坐标系里。这一步很关键，因为后续的投影和裁剪都依赖这个空间。然后是裁剪空间，通过投影矩阵（透视或正交）把视锥体外的顶点裁掉，同时为透视除法做准备。最后经过屏幕映射，把归一化设备坐标（NDC）转换成屏幕像素坐标。

这一套流程听起来线性，但实际写Shader的时候，很多人会在法线变换上翻车。法线不能直接用模型矩阵变换，因为模型矩阵可能包含非均匀缩放。比如你把一个球体在Y轴方向压扁，法线如果还用同一个矩阵变换，方向就错了。正确做法是用模型矩阵的逆转置矩阵来变换法线。这个坑我在早期做角色换装系统时踩过，当时角色一缩放，光照就全乱了，排查了大半天才发现是法线变换的问题。

提示：如果你用的是Three.js或Babylon.js这类引擎，它们的内置材质会自动处理法线变换。但一旦你开始写自定义Shader，这个细节就必须自己管。

2.2 光栅化与片元着色：像素是怎么被“填色”的

顶点处理完之后，GPU拿到的是屏幕空间中的三角形顶点。接下来的光栅化阶段，就是把这三个顶点构成的三角形，转换成一个个具体的像素位置。这个过程不是简单的“填充”，而是会计算每个像素的重心坐标，用来插值顶点属性——颜色、法线、UV坐标等等。

这里有一个容易被忽略的点：插值是在透视校正下进行的。什么意思？假设一个三角形一边离摄像机近，一边离得远，那么靠近摄像机的那部分像素，在插值时权重会更大。如果不做透视校正，纹理贴图在斜面上就会出现扭曲。这个机制是硬件自动处理的，但理解它有助于你明白为什么UV坐标在远处会“挤在一起”。

片元着色器是真正决定每个像素颜色的地方。你可以在这里采样纹理、计算光照、做各种效果。但要注意，片元着色器的执行次数等于屏幕上的像素数乘以重叠绘制的层数。一个覆盖全屏的物体，在1080p下就是200多万个片元。如果场景里有多个半透明物体叠加，这个数字会成倍增长。这就是为什么过度绘制（Overdraw）是移动端3D应用的头号性能杀手。

我做过一个数据可视化项目，最初为了效果好看，给每个数据点都加了一个半透明的光晕面片。结果在手机上，当数据点超过500个时，帧率直接从60掉到15。后来把光晕改成不透明的公告板纹理，配合Alpha Test而不是Alpha Blend，帧率立刻回到50以上。这个经验告诉我：在移动端，能不透明就不透明，能用Alpha Test就不用Alpha Blend。

2.3 深度测试与混合：谁在前谁在后

深度测试解决的是“遮挡”问题。每个片元在写入颜色缓冲区之前，会先比较它的深度值和深度缓冲区中已有的值。如果更近，就通过测试并更新深度；如果更远，就被丢弃。这个机制让GPU可以以任意顺序绘制不透明物体，最终结果都是正确的。

但深度测试有个前提：你不能在片元着色器里随意丢弃片元。如果你用了discard语句（比如做Alpha Test），那么在某些GPU架构上，深度写入会被禁用，导致后续的遮挡关系出错。这就是为什么很多引擎建议把Alpha Test的材质放在不透明物体之后、半透明物体之前绘制。

混合则是另一回事。当你要做半透明效果时，深度测试仍然进行，但深度写入通常要关闭，同时开启混合。混合的公式决定了源颜色和目标颜色如何组合。最常见的Alpha Blend是srcAlpha * srcColor + (1 - srcAlpha) * dstColor。但混合的代价是必须按从远到近的顺序绘制，否则半透明物体之间的遮挡关系就会错乱。

这里有一个实操中的经典问题：半透明物体互相穿插怎么办。比如两个半透明的玻璃球交叠在一起，无论你怎么排序，总有一个球的部分会被错误地遮挡。解决方案通常有三种：一是用深度剥离（Depth Peeling），但性能开销大；二是用顺序无关的透明（OIT），需要硬件支持；三是干脆接受这个瑕疵，或者用抖动透明（Dithering）来模拟。我在做建筑可视化时，遇到玻璃幕墙互相交叠的情况，最后选的是第三种方案——用屏幕空间抖动，在视觉上几乎看不出问题，性能却好了很多。

3. 场景组织：从一堆模型到一棵有逻辑的树

3.1 场景图不是万能药，但没有它万万不能

场景图（Scene Graph）是3D应用中最基础的数据结构。它本质上是一棵树，每个节点有自己的局部变换，子节点的世界变换等于父节点世界变换乘以自身局部变换。这个设计的好处是：当你移动一个父节点时，所有子节点自动跟着移动。比如一辆车，车轮是车的子节点，车开动时车轮自然跟着走，不需要单独更新每个轮子的位置。

但场景图也有它的代价。每次渲染前，你需要遍历整棵树，计算每个节点的世界矩阵。如果树很深，或者节点很多，这个遍历本身就会成为瓶颈。我见过一个项目，场景里有上万个独立的小零件，每个零件都是一个单独的节点，结果光是更新世界矩阵就占了每帧30%的时间。后来把这些零件合并成几个大的网格，性能立刻翻倍。

另一个常见误区是把所有东西都塞进场景图。比如天空盒、全屏后期效果、UI元素，这些东西其实不需要参与场景图的变换计算。把它们单独拿出来管理，反而更清晰。Three.js里就有Scene和Camera分离的设计，后期效果通常挂在EffectComposer上，而不是场景节点里。

3.2 空间划分：让GPU只画该画的东西

场景图解决了“物体在哪”的问题，但没解决“哪些物体需要画”的问题。一个复杂的场景可能有几十万个三角形，但摄像机视野里可能只有几千个。**视锥体剔除（Frustum Culling）**就是用来做这个筛选的：把每个物体的包围盒和摄像机的视锥体做相交测试，不相交的直接跳过。

但视锥体剔除的粒度是物体级别的。如果一个大物体横跨整个场景，比如地面，它的包围盒永远和视锥体相交，那就永远剔不掉。这时候就需要遮挡剔除（Occlusion Culling）。它的思路是：先画那些肯定可见的大物体，然后用它们的深度信息去测试其他物体是否被挡住。这个技术在室内场景特别有效，比如你在一个房间里，墙外的所有东西都可以被剔除掉。

不过遮挡剔除的实现复杂度很高，而且需要额外的CPU和GPU开销。我的经验是：如果场景是室外开阔环境，视锥体剔除就够了；如果是室内或城市密集场景，才值得上遮挡剔除。而且现在很多引擎（如Unity、Unreal）都内置了烘焙好的遮挡数据，直接用就行，没必要自己从头写。

还有一个更细粒度的优化是细节层次（LOD）。同一个物体，距离远的时候用低模，距离近的时候用高模。这个切换距离需要根据屏幕上的像素大小来定，而不是简单的世界距离。因为一个巨大的物体，即使离得远，在屏幕上也可能占很大面积。我通常会把LOD切换阈值设在“物体在屏幕上投影高度小于屏幕高度5%”的时候。

3.3 实例化与合批：减少Draw Call的艺术

Draw Call是CPU向GPU发送的绘制命令。每次Draw Call都有固定的CPU开销，包括状态切换、参数设置等。如果场景里有1000个相同的树模型，每个都单独Draw Call，CPU就会成为瓶颈。**实例化（Instancing）**允许你用一次Draw Call画出所有树，每棵树的位置、旋转、缩放通过顶点属性传入。

实例化在植被、粒子、人群这类重复元素多的场景里效果极其明显。我做过一个森林场景，用实例化之前，1000棵树要1000次Draw Call，帧率只有20；改成实例化后，1次Draw Call搞定，帧率直接飙到120。但实例化也有局限：所有实例必须共享同一个网格和材质。如果每棵树需要不同的颜色或形状，就得用顶点属性来传递差异，或者退回到合批。

合批（Batching）是另一种思路：把多个小网格合并成一个大网格，一次性画出来。静态合批在加载时就把网格合并好，适合不会移动的物体，比如建筑、地形装饰。动态合批则在每帧运行时合并，适合会移动但顶点数很少的物体。Unity里对动态合批的顶点数有限制（通常300个顶点以内），超过就不合了。

这里有一个我踩过的坑：合批会破坏视锥体剔除的粒度。如果你把整个城市的建筑合并成一个网格，那么即使你只看一栋楼，GPU也得把整个城市的三角形都处理一遍。所以合批和剔除需要权衡。我的做法是：按空间区域分组合批，比如每100米见方作为一个合批单元，这样既能减少Draw Call，又保留了剔除的灵活性。

4. 光照与材质：让3D物体看起来“像那么回事”

4.1 从Lambert到PBR：光照模型的演进逻辑

最早的光照模型是Lambert漫反射，只考虑光线方向和表面法线的夹角。它简单、快，但看起来像塑料。后来加了Phong高光，能模拟光滑表面的反光，但高光形状是圆的，不够真实。再后来是Blinn-Phong，把高光计算简化了一步，效果差不多但更快。

现在的主流是基于物理的渲染（PBR）。PBR的核心思想是：用物理参数来描述材质，而不是用经验参数。比如金属度（Metalness）和粗糙度（Roughness），这两个参数直接对应现实世界中的材质属性。金属度高就是金属，粗糙度低就是光滑。PBR的好处是，在不同光照环境下，材质的表现是一致的，不会出现“在这个场景里好看，换个场景就崩了”的情况。

但PBR的计算量比Lambert大得多。一个完整的PBR着色器，需要计算直接光照、间接光照、环境反射、菲涅尔效应等等。在移动端，通常会用简化版的PBR，比如只计算直接光照，环境光用一张预计算的球谐函数（SH）来近似。我在做移动端电商3D展示时，用的就是这种方案：产品模型用PBR材质，但环境光只用一个简单的SH，效果足够好，性能也扛得住。

注意：PBR材质的效果高度依赖环境贴图。如果你只给了一个纯色环境光，PBR材质看起来会和Lambert差不多。所以做PBR的时候，一定要配一张HDR环境贴图，哪怕分辨率低一点。

4.2 阴影：最影响真实感也最吃性能的部分

阴影是3D图形里“真实感”的最大来源之一。没有阴影，物体就像飘在空中。但阴影也是性能开销最大的部分之一。主流的阴影技术是阴影贴图（Shadow Map）：从光源的角度渲染一遍场景，把深度信息存到一张纹理里，然后在主渲染时，把每个像素的世界坐标转换到光源空间，和阴影贴图比较深度，判断是否在阴影中。

阴影贴图的质量取决于分辨率。分辨率越高，阴影边缘越锐利，但显存和带宽开销也越大。一个2048x2048的阴影贴图，在移动端可能就占用了好几MB的显存。而且如果场景很大，一张阴影贴图覆盖整个场景，每个物体分到的像素就很少，阴影会变得很糊。

解决方案是级联阴影贴图（CSM）：把视锥体分成几个层级，近处用高分辨率阴影贴图，远处用低分辨率。这样既保证了近处阴影的清晰度，又控制了总体开销。CSM在Unity和Unreal里都是默认开启的，但参数需要根据场景调整。我通常会把级联数量设为4，近处分辨率2048，远处1024，过渡区域用淡入淡出避免接缝。

另一个常见问题是阴影偏移（Shadow Bias）。由于阴影贴图的分辨率有限，直接比较深度会出现“阴影痤疮”（Shadow Acne）——物体表面出现条纹状的自我阴影。解决办法是给深度比较加一个偏移量。但偏移量太大会导致“彼得潘效应”（Peter Panning）——阴影和物体分离，看起来像飘在空中。这个偏移量需要根据场景尺度和光照角度来调，没有万能值。我的经验是：从0.005开始试，如果还有痤疮就加大，如果阴影飘了就减小。

4.3 材质系统设计：如何管理成百上千种材质

一个稍微复杂点的3D项目，材质数量很容易上百。如果每个材质都单独一个Shader，编译和切换的开销会很大。所以需要一套材质系统来管理。

常见的做法是基于Shader变体（Shader Variant）。一个基础Shader，通过宏定义来开启或关闭不同的功能，比如是否用纹理、是否用光照贴图、是否用雾效。这样GPU只需要编译有限几个变体，而不是每个材质一个独立Shader。Unity的Standard Shader就是这种思路，它有一个庞大的变体集合，但实际运行时只会编译用到的那些。

但变体太多也会导致编译时间过长和包体膨胀。我见过一个项目，Standard Shader的变体有上万种，打包时光编译Shader就花了半小时。后来通过剥离未使用的变体，把数量降到了几百种，打包时间缩短到几分钟。具体做法是：在项目设置里，只保留实际用到的关键字组合，其他的全部剔除。

另一个思路是材质实例化。同一个Shader，不同的参数值（颜色、纹理、数值），可以共享同一个编译好的Shader程序，只是Uniform不同。这样切换材质时，不需要重新编译Shader，只需要更新Uniform。Three.js里的ShaderMaterial和RawShaderMaterial就支持这种模式。我在做参数化产品配置器时，就是用一套Shader加不同的Uniform，让用户实时调整颜色、材质、纹理，完全没有卡顿。

5. 性能优化：从能跑到跑得爽的实战路径

5.1 先定位瓶颈：CPU还是GPU

性能优化最忌讳的就是“凭感觉猜”。你觉得是GPU太慢，结果加了半天优化，发现是CPU在提交Draw Call时卡住了。所以第一步永远是定位瓶颈。

在浏览器里，可以用Chrome的Performance面板，看每一帧的时间分布。如果Scripting和Rendering占比高，说明CPU是瓶颈；如果GPU占比高，或者帧率低但CPU很闲，那就是GPU瓶颈。在移动端，可以用Xcode的GPU Capture或Android的GPU Inspector，看每个Draw Call的耗时。

一个简单的判断方法：把渲染分辨率降到原来的一半。如果帧率翻倍，说明是GPU的像素填充率瓶颈；如果帧率没变，说明是CPU的Draw Call或逻辑瓶颈。这个方法我用了很多年，几乎百试百灵。

5.2 GPU瓶颈的常见解法

如果是GPU瓶颈，首先要看是顶点瓶颈还是像素瓶颈。把场景里的模型换成最简单的立方体，如果帧率大幅提升，说明是顶点处理或几何复杂度的问题；如果帧率没变，说明是像素着色或过度绘制的问题。

顶点瓶颈的解法包括：减面、用LOD、用实例化、减少骨骼数量。像素瓶颈的解法包括：降低分辨率、减少半透明物体、简化片元着色器、用更高效的纹理压缩格式。

这里重点说一下纹理压缩。一张2048x2048的RGBA纹理，未压缩时占16MB显存。如果换成ASTC或ETC2压缩格式，可以降到2MB左右，而且GPU采样时带宽占用也大幅降低。但压缩纹理是有损的，对于法线贴图这种对精度要求高的纹理，需要选择高质量的压缩格式，或者干脆不压缩。我的经验是：颜色贴图用ASTC 6x6或ETC2，法线贴图用ASTC 4x4或未压缩。

5.3 CPU瓶颈的常见解法

CPU瓶颈通常来自三个方面：Draw Call太多、物理计算太重、逻辑更新太频繁。

Draw Call的优化前面已经说了，实例化和合批是主要手段。但还有一个容易被忽略的点：状态切换。每次切换Shader、纹理、渲染目标，都有CPU开销。所以要把使用相同状态的物体放在一起画。比如所有不透明物体先画，所有半透明物体后画；所有用同一张纹理的物体连续画。

物理计算方面，如果用了物理引擎，要确保碰撞体尽量简单。一个复杂的网格碰撞体，物理引擎需要处理成千上万个三角形，而一个盒体碰撞体只需要处理12个。我在做VR交互时，所有可抓取的物体都用盒体或球体碰撞体近似，只有需要精确碰撞的地方才用网格碰撞体。

逻辑更新方面，不要每帧更新所有东西。比如远处的NPC，可以每几帧更新一次AI；不活跃的粒子系统，可以暂停更新。Unity里的Update和FixedUpdate要合理使用，物理相关的放FixedUpdate，视觉相关的放Update。

5.4 内存与加载优化

3D应用的内存占用往往被低估。一个未压缩的2048x2048纹理就是16MB，十个就是160MB。再加上网格数据、动画数据、音频，很容易就超过移动端的内存限制。

纹理方面，除了压缩，还要注意Mipmap。Mipmap会让纹理内存增加33%，但能大幅提升渲染性能和画质。对于远处物体，没有Mipmap会导致严重的闪烁。所以除了UI纹理，其他纹理都应该生成Mipmap。

网格方面，顶点属性要精简。如果不需要切线空间，就不要存切线和副切线。如果不需要顶点色，就不要存颜色。每个顶点属性都是内存和带宽的开销。我见过一个项目，所有模型都带着顶点色，但实际上根本没用，白白浪费了25%的顶点内存。

加载方面，异步加载和分帧加载是关键。不要在某一帧加载所有资源，而是分散到多帧，或者用Web Worker在后台加载。Three.js的LoadingManager和GLTFLoader都支持异步加载，但要注意加载完成后的回调时机，避免在渲染中途插入大量计算。

6. 跨平台适配：一套代码跑在手机、PC和网页上

6.1 精度问题：highp、mediump和lowp的选择

在移动端GPU上，浮点精度是有限制的。highp在顶点着色器里通常没问题，但在片元着色器里，有些老设备不支持。mediump精度较低，但对于颜色计算、UV插值通常够用。lowp精度最低，适合做简单的开关判断。

我的经验是：顶点着色器用highp，片元着色器默认用mediump，只有确实需要高精度的地方（比如世界坐标计算）才用highp。在Three.js里，可以通过precision参数来设置默认精度。如果设置成mediump，所有Shader默认都是mediump，需要highp的地方再单独声明。

精度问题最典型的症状是画面出现色带或抖动。比如一个渐变背景，在mediump下可能出现明显的条纹。这时候要么提高精度，要么用抖动（Dithering）来掩盖。我在做移动端H5时，遇到过天空盒渐变出现色带的问题，后来在片元着色器里加了一点随机噪声，色带就消失了。

6.2 渲染API差异：WebGL、WebGL2和WebGPU

WebGL 1.0基于OpenGL ES 2.0，功能有限，不支持实例化、多重采样、浮点纹理等特性。WebGL 2.0基于OpenGL ES 3.0，支持这些特性，但兼容性稍差。WebGPU是最新的API，性能更好，但支持度还在普及中。

如果要做跨平台，优先用WebGL 2.0，降级到WebGL 1.0。Three.js会自动检测并选择合适的渲染器。但要注意，WebGL 1.0下有些特性不可用，比如InstancedMesh在WebGL 1.0下需要扩展支持。如果目标设备包括老手机，就要做好降级方案。

WebGPU目前主要在Chrome和Edge上可用，Safari和Firefox还在推进中。如果项目面向的是最新浏览器，可以考虑用WebGPU，但要做好回退到WebGL的准备。Babylon.js和Three.js都在逐步支持WebGPU，但生态还在完善中。

6.3 输入方式适配：鼠标、触摸和手柄

PC上用鼠标，手机上用触摸，VR用手柄，这是三种完全不同的交互方式。鼠标有悬停（Hover）状态，触摸没有；触摸有多点触控，鼠标没有；手柄有扳机和摇杆，鼠标触摸都没有。

做跨平台3D应用时，交互逻辑要抽象成统一的接口。比如“选择物体”这个操作，鼠标是点击，触摸是轻触，手柄是扳机键。底层用同一套射线检测（Raycasting）逻辑，上层根据输入设备分发不同的事件。

触摸操作还有一个特殊问题：手指遮挡。在手机上，用户的手指会挡住屏幕的一部分，如果交互元素在手指下方，用户就看不见了。解决方案是把交互元素放在手指上方，或者用偏移量把射线检测的位置往上移。我在做移动端3D配置器时，把拖拽旋转的灵敏度调低了一些，同时把确认按钮放在屏幕底部，避免被手指挡住。

7. 我踩过的那些坑：几个真实案例的复盘

7.1 案例一：法线贴图在移动端失效

有一次做移动端产品展示，PC上法线贴图效果很好，到了手机上却完全没效果，模型看起来像塑料。排查后发现，移动端GPU对法线贴图的压缩格式支持不同。PC上用的BC5压缩，手机上不支持，自动降级成了RGB格式，但法线贴图的RGB通道被压缩后精度损失严重，导致法线方向错误。

解决方案是：移动端用法线贴图时，不要压缩，或者用ASTC格式并选择高质量模式。如果显存实在紧张，可以把法线贴图的分辨率降一半，但保持未压缩。后来我把法线贴图从2048降到1024，未压缩，效果和PC上基本一致，显存占用也在可接受范围内。

7.2 案例二：阴影在远处出现锯齿和闪烁

一个室外场景，阴影在近处还好，远处就出现严重的锯齿和闪烁。原因是阴影贴图的分辨率不够，远处一个像素覆盖了很大的世界空间。解决方案是级联阴影贴图（CSM），把视锥体分成近、中、远三层，每层用不同的阴影贴图。近处用2048，中处用1024，远处用512。这样近处阴影清晰，远处虽然分辨率低，但因为距离远，视觉上不明显。

但CSM也有坑：层级之间的过渡区域会出现接缝。如果直接切换，阴影会突然变化。解决办法是在过渡区域做淡入淡出，让两个层级的阴影按距离混合。Unity的CSM默认就带这个功能，但参数需要调。我通常会把过渡区域设为层级范围的10%左右，太窄了接缝明显，太宽了性能开销大。

7.3 案例三：大量半透明粒子导致帧率暴跌

一个烟花效果，用了上千个半透明粒子。PC上还好，手机上直接卡成PPT。原因是过度绘制：每个粒子都覆盖屏幕的一部分，半透明混合需要读取目标颜色，带宽开销巨大。而且粒子没有排序，混合顺序错误，看起来也乱。

解决方案分三步：第一，把粒子纹理改成Alpha Test而不是Alpha Blend，这样不需要混合，也不需要排序。第二，用GPU粒子代替CPU粒子，把粒子模拟放到顶点着色器里，减少CPU开销。第三，限制粒子的最大数量，根据设备性能动态调整。改完之后，手机上也能跑到40帧以上，效果虽然比PC上稍差，但完全可接受。

7.4 案例四：场景加载时的卡顿和内存峰值

一个大型场景，加载时卡顿严重，内存峰值也很高。排查发现，所有纹理和网格都在同一帧加载，导致CPU和GPU都忙不过来。解决方案是分帧加载：把资源分成多个批次，每帧加载一批，加载完一批再加载下一批。同时用占位符先显示，等真实资源加载完再替换。

另一个问题是纹理没有及时释放。切换场景时，旧场景的纹理没有销毁，内存一直涨。后来加了引用计数，每个纹理被引用时计数加一，不再引用时减一，减到零就销毁。这个机制在Three.js里需要手动管理，texture.dispose()要记得调用。

8. 工具链与调试：怎么快速定位3D图形问题

8.1 浏览器端的调试利器

Chrome的DevTools里有WebGL Inspector，可以查看每一帧的Draw Call、纹理、Shader。但更强大的是Spector.js，它是一个浏览器扩展，能捕获一整帧的所有WebGL调用，包括每个Draw Call的顶点数据、纹理绑定、Uniform值。我每次遇到渲染结果不对，第一件事就是用Spector.js抓一帧，看看实际传给GPU的数据是什么。

另一个常用工具是RenderDoc，它支持WebGL和WebGPU，能捕获GPU管线的完整状态。但RenderDoc对WebGL的支持有限，更适合桌面端的OpenGL和Vulkan。如果是Unity或Unreal项目，直接用引擎自带的Profiler和Frame Debugger就够了。

8.2 移动端的调试方法

移动端调试3D图形比较麻烦，因为不能直接连DevTools。常用的方法有：Safari的Web Inspector（需要Mac和iOS设备），Chrome的Remote Debugging（需要Android设备和USB连接）。连接后，可以在桌面浏览器里查看手机上的页面，用同样的DevTools调试。

如果问题只在特定设备上出现，可以用远程日志：在代码里把关键信息（帧率、Draw Call数、内存占用）输出到页面上，或者发送到服务器。我在做移动端项目时，会在角落放一个小的性能面板，显示FPS、Draw Call、三角形数量，方便快速判断性能状况。

8.3 性能监控的常态化

不要等到出问题了才去优化。在开发阶段就加入性能监控，每帧记录FPS、Draw Call、三角形数、内存占用。设置阈值，超过就报警。这样可以在问题恶化之前就发现并解决。

我通常会在项目里加一个Stats面板（Three.js有现成的Stats.js），显示实时帧率。同时用performance.now()记录关键函数的耗时，比如场景更新、物理计算、渲染提交。这些数据在优化时非常有用，能直接告诉你时间花在哪里了。

9. 写给不同阶段开发者的建议

9.1 刚入门的新手：先跑通再优化

如果你刚开始学3D图形，不要一上来就追求PBR、阴影、后期效果。先用最简单的Lambert材质，画几个立方体和球体，理解坐标系、相机、光照的基本概念。然后逐步加纹理、加法线贴图、加阴影。每加一个特性，都观察帧率的变化，理解这个特性的性能代价。

我见过很多新手，跟着教程做了一个很炫的效果，但完全不知道背后的原理，换个场景就不会用了。理解比复制更重要。每个效果，都要问自己：这个效果是怎么实现的？用了哪些数据？计算量在哪里？能不能简化？

9.2 有经验的开发者：关注架构和工具链

如果你已经能熟练使用Three.js或Unity，下一步应该关注架构设计和工具链建设。比如：如何设计一套可扩展的材质系统？如何管理场景的加载和卸载？如何做性能监控和自动化测试？

工具链方面，自动化构建和部署能节省大量时间。比如用Webpack或Vite打包，用CI/CD自动部署到测试环境。资源管线也很重要：模型从DCC工具导出时，自动做减面、压缩纹理、生成LOD。这些自动化流程能避免很多手动操作的错误。

9.3 技术负责人：平衡效果、性能和开发成本

如果你负责一个3D项目的技术决策，最重要的能力是权衡。老板想要电影级画质，但用户手机只有千元机；设计师想要实时全局光照，但开发周期只有两个月。这时候你需要给出分级的方案：高端设备开全效果，中端设备降分辨率关阴影，低端设备用最简化的渲染。

我的经验是：先保证核心体验流畅，再逐步提升画质。一个流畅的简单场景，比一个卡顿的复杂场景，用户留存率高得多。而且性能优化不是一次性的工作，应该贯穿整个开发周期。每加一个特性，都要评估它的性能影响，及时调整。

10. 最后分享几个我常用的性能检查清单

每次项目上线前，我都会过一遍这个清单。虽然简单，但能避免很多低级问题：

• Draw Call数量：移动端控制在100以内，PC端控制在1000以内。超过就要考虑合批或实例化。
• 三角形数量：移动端单帧不超过10万，PC端不超过100万。超过就要减面或LOD。
• 纹理内存：移动端不超过100MB，PC端不超过500MB。超过就要压缩或降分辨率。
• 半透明物体数量：尽量控制在10个以内。超过就要考虑用Alpha Test或抖动透明。
• Shader变体数量：打包前检查，剥离未使用的变体。超过1000个就要警惕。
• 帧率稳定性：不要只看平均帧率，要看最低帧率。最低帧率低于30就会明显卡顿。

还有一个我个人的习惯：在低端设备上测试。不要只在开发机上跑，找一台几年前的手机，或者用Chrome的CPU Throttling模拟低性能设备。很多问题只有在低端设备上才会暴露出来。

3D图形这个领域，说深很深，说浅也很浅。核心概念就那么几个，但每个概念背后的细节和权衡，需要大量的实践才能体会。我写这篇东西，不是想覆盖所有内容，而是想把那些教科书上不会写、但实际项目中一定会遇到的东西分享出来。如果你在做3D项目的过程中遇到了什么问题，或者有更好的解决方案，欢迎一起交流。这个领域变化很快，新技术层出不穷，保持学习和动手实践，比什么都重要。