Web 端 3D 开发的实用技术栈梳理

四、智慧工厂场景里，常见的增强项

在智慧工厂里，3D 只是底图，真正让系统能用的往往是叠加层。

D3.js、ECharts 这类可视化库，适合做设备数据面板、趋势图、状态分布图。Three.js CSS2DRenderer 则适合把 DOM 元素挂到 3D 空间里，设备标签、告警提示、悬浮信息都会更自然。

物理模拟方面，Ammo.js 和 Rapier.js 都能用。前者是 Three.js 圈子里更常见的选择，后者更轻量。AGV 避障、碰撞检测、简单约束模拟，这些需求不一定都要上完整物理系统，但有时它能省掉很多手工判断。

动画和路径规划则更偏业务实现。Tween.js、GSAP 做设备运动够直接；要做 AGV 调度可视化，通常还是得配合自己的寻路逻辑，A* 只是起点，不是终点。

五、工程化这块，别等到后面再补

项目一旦进入工程化阶段，Vite + TypeScript 基本是比较稳的组合。TypeScript 对 Three.js 的类型支持虽然有时不算省心，但在资产多、交互多的项目里，类型约束能少踩不少坑。

模型资源也需要处理。gltf-pipeline 做 glTF 压缩、配合 Draco，通常是值得的，尤其是模型体积开始上来以后。资源分发尽量走 CDN，不然模型文件和纹理一多，主服务器带宽很快就会吃紧。

SSR 这件事也别想当然。大多数 3D Web 应用更适合 CSR，服务端渲染并不会天然带来收益，反而容易在 WebGL、浏览器 API 这些地方撞墙。

六、我会怎么排学习顺序

graph LR
    A[Blender 基础建模] --> B[掌握 glTF 导出规范]
    B --> C[Three.js 核心概念]
    C --> D[React Three Fiber 项目实战]
    D --> E[集成实时数据 MQTT/WebSocket]
    E --> F[添加 GIS/Cesium 大地形]
    F --> G[性能优化与部署]

这条路径的意思很简单：先把资产和渲染打通，再上交互和数据，最后才轮到大场景和性能。顺序反过来，通常只会把自己绕晕。

七、一个更贴近实际的开发流程

先在 Blender 里把设备模型做出来，尽量控制面数，烘焙纹理后导出 glTF。前端再用 R3F 或原生 Three.js 接进来，模型加载后，把状态绑定到材质、位置或动画上。

// React Three Fiber 示例
import { useGLTF } from '@react-three/drei';

function Machine({ status }) {
  const { nodes } = useGLTF('/assembly-line.glb');
  return (
    <mesh geometry={nodes.conveyor.geometry} material={status === 'error' ? redMaterial : defaultMaterial} />
  );
}

// 通过 WebSocket 更新状态
socket.on('machine-update', (data) => {
  store.dispatch(updateMachineStatus(data.id, data.status));
});

这类代码看着简单，真正费时间的地方往往不是写组件，而是把数据更新、资源管理和动画状态理顺。

避坑时最常见的几个点

• Blender 里默认单位是 1 单位 = 1 米，比例不统一，前端里再怎么调都别扭。
• Blender 和 Three.js 的坐标系不一致，导入后通常要做转换。
• Geometry、Material 该释放就释放，不然内存泄漏会慢慢拖垮页面。
• iOS 上有些渲染异常，要留意 useLegacyLights 这类兼容配置。

如果你已经能把一个具体设备，比如传送带状态监控，完整做出来，再往整条产线、整厂区扩展，路就清楚很多。WebGPU 也值得持续关注，但它更像下一阶段的能力储备，不是现在就必须押注的全部答案。