企业官网建设流程全解析

1. 从标题拆解这个项目的真实意图

1.1 为什么是“智慧仓储”而不是别的场景

“Antigravity + Blender MCP（上）：打造3D 智慧仓储数字孪生”这个标题，信息密度其实很高。拆开来看，三个关键词各自承担了不同职责：Antigravity是开发环境与智能体协作层，Blender MCP是三维资产的生产与联动通道，智慧仓储数字孪生是最终要交付的业务形态。三者串起来，本质上是一条“用 AI 辅助工具链，把三维场景从建模到前端渲染全流程打通”的工程路径。

为什么选智慧仓储作为落地场景？做过数字孪生项目的人都知道，仓储是三维可视化里性价比极高的题材。它的空间结构规整——货架、巷道、堆垛机、AGV、传送带，全是标准几何体组合；它的业务逻辑清晰——入库、上架、拣选、出库，每个环节都能映射到具体模型的状态变化；它的数据维度丰富——库位占用率、设备运行状态、订单流转速度，天然适合做实时数据驱动。相比之下，园区级数字孪生动辄要处理地形、建筑外立面、绿化、管网，模型量大且业务逻辑松散，新手很容易在资产整理阶段就耗光耐心。

我自己的经验是，第一次做数字孪生，选仓储比选园区至少省掉百分之四十的无效工作量。因为仓储场景里，你不需要纠结“这棵树要不要做LOD”“这栋楼的玻璃反射怎么调”，所有精力都可以集中在“货架怎么摆”“AGV怎么动”“数据怎么绑”这三件核心事情上。

1.2 Antigravity 在这个链路里扮演什么角色

Antigravity 是一个智能体驱动的开发环境，它的价值不在于替代 Blender 或 Three.js，而在于把“写脚本、调参数、查文档、改代码”这些碎片化动作串成一条可对话的工作流。举个例子：你在 Blender 里手动摆放两百个货架，可能要花一整个下午；但如果你用 Antigravity 写一段 Python 脚本，通过 Blender 的 bpy 接口批量生成货架阵列，再根据库位编号自动命名，整个过程压缩到十分钟以内。

更关键的是，Antigravity 能理解上下文。你可以直接告诉它“帮我把这批货架的间距从 1.5 米改成 2 米，同时保持巷道中线对齐”，它会生成对应的变换逻辑，而不是让你去翻 Blender API 文档找bpy.ops.transform.translate的参数。这种交互方式对前端出身、三维经验偏弱的开发者特别友好——你不需要成为 Blender 专家，只需要能把需求描述清楚。

1.3 Blender MCP 解决的是什么痛点

MCP 是 Model Context Protocol 的缩写，本质是一套让外部工具与 Blender 实时通信的协议层。没有它的时候，Blender 和前端代码之间是断开的：你在 Blender 里调完模型，导出 glTF，再手动拖进项目目录，前端刷新才能看到效果。改一个材质颜色，就要重复一遍“改-导出-替换-刷新”的循环，效率极低。

Blender MCP 把这个循环缩短到近乎实时。你在 Blender 里移动一个货架，前端页面上的对应模型同步位移；你在前端点击某个库位，Blender 里对应的对象高亮显示。这种双向联动在调试阶段特别有用，尤其是处理“模型位置对不上数据坐标”这类问题时，肉眼比对比看控制台日志快得多。

注意：Blender MCP 目前对 Blender 版本有要求，建议使用 3.6 LTS 及以上。版本过低会导致部分接口调用失败，表现为“连接成功但指令无响应”。

1.4 这个项目适合谁来参考

如果你符合以下任意一条，这篇内容值得你花时间读完：

• 有 Vue 3 或 React 基础，想切入 Three.js 三维可视化，但不知道从哪个场景练手；
• 做过简单 Three.js demo，但模型一多就卡顿，想学资产优化和实例化渲染；
• 在用 Blender 做数字孪生资产，但被“导出-导入”的重复劳动折磨；
• 对 Antigravity 这类智能体开发环境感兴趣，想看看它在三维工作流里到底能帮上什么忙。

如果你完全没有前端基础，也没有接触过任何三维软件，建议先补一下 Vue 3 的组件通信和 Three.js 的场景图概念，否则后面讲“数据驱动模型状态”的部分会有些吃力。

2. 整体架构设计与技术选型逻辑

2.1 为什么前端选 Vue 3 + Three.js 而不是 Unity WebGL

热词里出现了“unity数字孪生”，说明很多人第一反应是用 Unity 做数字孪生。Unity 的优势在于渲染质量高、物理引擎成熟、编辑器可视化强。但放到 Web 端数字孪生这个具体场景里，它有几个绕不开的问题。

第一是包体。一个最简 Unity WebGL 构建产物，压缩后通常也在 15MB 以上，首屏加载时间在普通网络环境下很难压到 3 秒以内。而 Three.js 项目如果做好按需加载和模型压缩，首屏控制在 2MB 以内是完全可以做到的。数字孪生页面往往要嵌入企业后台系统，用户不会容忍等十几秒才看到画面。

第二是交互定制成本。Unity WebGL 与外部 JavaScript 的通信需要通过SendMessage和jslib，数据双向绑定的写法比较绕。而 Vue 3 + Three.js 的方案里，三维场景本身就是前端应用的一部分，Vue 的响应式数据可以直接驱动 Three.js 对象的属性变化，不需要跨运行时通信。

第三是团队技能栈。国内大部分数字孪生项目的前端团队，Vue 或 React 是标配，但会 Unity C# 的人往往不在同一个组。用 Vue 3 + Three.js，前端工程师可以独立完成从页面布局到三维渲染的全部工作，不需要等三维组排期。

当然，Unity 也有它的适用场景：如果项目需要复杂的物理仿真（比如碰撞检测精度要求高）、或者需要复用已有的 Unity 资产库，那 Unity WebGL 仍然是更优解。但对于“仓储设备沿固定路径运动 + 货架状态变色 + 数据面板联动”这类需求，Three.js 完全够用，而且更轻、更可控。

2.2 数字孪生的“孪生”到底体现在哪里

很多人做出来的东西，严格来说只能叫“三维可视化”，不能叫“数字孪生”。区别在于：可视化是静态的、单向的，模型只是好看；孪生是动态的、双向的，模型状态与真实数据保持映射关系。

具体到仓储场景，孪生关系至少体现在三个层面：

第一层是空间孪生。货架的位置、巷道的宽度、设备的尺寸，必须与真实仓库的 CAD 图纸或激光扫描数据一致。这一层靠 Blender 建模时按真实尺寸建模来保证，单位统一用米，导出时不做额外缩放。

第二层是状态孪生。每个库位是空置、占用还是锁定，每台 AGV 是在充电、待命还是执行任务，这些状态要实时反映在模型上。实现方式通常是给模型对象挂载userData，里面存业务 ID，前端拿到后端推送的数据后，根据 ID 找到对应对象，修改材质颜色或播放动画。

第三层是行为孪生。AGV 的行驶路径、堆垛机的升降动作、传送带的运转速度，这些动态行为要与真实设备的运行逻辑一致。这一层最复杂，通常需要后端提供设备实时位置或任务队列，前端做插值平滑。

我见过不少项目只做了第一层就交付了，客户验收时问“为什么货架不会变颜色”，才发现数据对接根本没做。所以在架构设计阶段，就要把“数据从哪来、怎么推、推给谁、谁改模型”这条链路想清楚。

2.3 Blender MCP 的接入位置与数据流向

整个系统的数据流向可以这样描述：

真实仓库数据源（WMS/WCS） ↓ 后端服务（WebSocket / SSE 推送） ↓ Vue 3 应用层（状态管理 + 业务逻辑） ↓ Three.js 场景层（模型状态更新 + 渲染） ↑ Blender MCP（资产生产阶段的实时联动）

Blender MCP 主要作用于资产生产阶段，也就是“从 Blender 到 Three.js”这一段。它的价值在于：当你在 Blender 里调整模型时，Three.js 场景能实时看到变化，不需要反复导出。但到了运行阶段，Blender 就不参与了，数据直接从后端流向 Three.js。

这个边界要划清楚，否则容易陷入“运行时还要连 Blender”的误区。Blender 是生产工具，不是运行时组件。

2.4 技术选型对照表

选型没有绝对优劣，关键是匹配团队能力和项目需求。仓储数字孪生的交互复杂度不高，Vue 3 + Three.js 是投入产出比最高的组合。

3. 核心细节解析与实操要点

3.1 Blender 建模阶段的单位与坐标规范

这一节讲的是最容易埋坑的地方。很多项目后期出现“模型位置对不上数据坐标”“AGV 走到货架里面去了”，根源都在建模阶段没有统一规范。

单位统一。Blender 默认单位是米，但新建场景时如果没注意，可能被改成厘米或英寸。检查方式：Scene Properties → Units → Unit System选Metric，Scale设为1.0。导出 glTF 时，Blender 会自动做单位转换，但如果源文件单位不对，转换结果就是错的。

坐标原点。建议把仓库地面的中心点放在世界原点(0, 0, 0)，Z 轴向上。这样前端加载模型后，相机环绕的中心就是仓库中心，不需要额外做偏移。如果建模时原点在角落，前端就要手动计算包围盒中心，多一步操作就多一个出错点。

命名规范。这是最容易被忽视但后期最省事的一步。货架命名建议用Rack_A01、Rack_A02这种格式，其中A表示巷道编号，01表示货架序号。AGV 命名用AGV_001、AGV_002。这样前端拿到业务数据里的rackId: "A01"，直接拼字符串就能找到对应对象，不需要维护额外的映射表。

实操心得：在 Blender 里用 Antigravity 写一段批量重命名脚本，比手动一个个改快得多。脚本逻辑是遍历选中对象，按“前缀+序号”的规则重命名，序号从 1 开始递增。

朝向统一。所有货架的正面朝向要一致，通常设为+Y方向。AGV 的车头朝向也要统一，建议设为+X方向。这样前端做路径动画时，只需要旋转 Y 轴角度，不需要考虑每个模型初始朝向不同的问题。

3.2 模型轻量化的三个关键操作

Three.js 场景卡顿，九成原因是模型面数太高或材质太复杂。Blender 里做好这三步，能省掉后期大量优化时间。

第一步：减面。货架上的螺栓、孔洞、标签这些细节，在数字孪生视角下根本看不清，但会贡献大量三角面。用Decimate修改器，比例设为0.3到0.5，能在几乎不损失轮廓的前提下减少一半以上面数。对于标准货架，一个单元控制在 500 面以内是合理目标。

第二步：合并同材质对象。一个货架如果有立柱、横梁、层板三个对象，材质相同的话，在 Blender 里用Ctrl+J合并成一个对象。这样导出后就是一个 mesh，前端渲染时 draw call 少两次。两百个货架就是四百次 draw call 的差距，对帧率影响很明显。

第三步：烘焙贴图替代复杂材质。如果货架上有 logo 或标识，不要用单独的材质节点，而是烘焙成一张贴图，贴到合并后的 mesh 上。glTF 导出时，一张 512x512 的贴图比三个材质节点更轻量。

三项叠加，一个两百货架的场景，帧率从 30fps 提升到 55fps 是常见结果。

3.3 Blender MCP 的连接配置与常见报错

Blender MCP 的连接分两步：Blender 端启用插件并开启服务，前端或 Antigravity 端配置连接地址。

Blender 端的操作路径是：Edit → Preferences → Add-ons → 搜索 MCP → 启用。启用后在 3D 视图侧边栏会出现 MCP 面板，点击Start Server，默认监听localhost:9876。如果端口被占用，可以在面板里改成其他端口。

Antigravity 端的配置通常是在项目设置里填入mcp://localhost:9876，具体格式取决于 Antigravity 版本。配置成功后，Antigravity 的对话窗口会显示“Blender connected”之类的状态提示。

常见报错及处理方式：

注意：如果 Antigravity 出现“agent execution terminated due to error”这类提示，先检查 MCP 连接状态，再检查脚本里是否有语法错误。多数情况下是脚本问题，不是连接问题。

3.4 数据绑定的设计模式

前端拿到后端推送的数据后，怎么找到对应的 Three.js 对象并更新状态？最直接的方式是遍历场景，用object.name匹配业务 ID。但场景对象多了以后，遍历开销不可忽视。

更高效的做法是在场景初始化时建一个索引表：

const objectMap = new Map(); scene.traverse((obj) => { if (obj.userData.bizId) { objectMap.set(obj.userData.bizId, obj); } });

这样数据来了以后，objectMap.get(rackId)是 O(1) 查找，比遍历快一个数量级。userData.bizId的值可以在 Blender 导出前写入自定义属性，也可以在 Three.js 加载 glTF 后根据对象名称批量赋值。

状态更新的逻辑建议封装成独立函数，比如updateRackStatus(rackId, status)，内部根据 status 切换材质颜色。这样业务层不需要关心 Three.js 的材质 API，只负责调函数传参。

4. 实操过程与核心环节实现

4.1 用 Antigravity 批量生成货架阵列

手动摆放货架是纯体力活，用 Antigravity 生成脚本可以把这个过程压缩到几分钟。以下是我实际用过的脚本逻辑，基于 Blender 的 bpy 接口。

假设仓库有 4 条巷道，每条巷道两侧各 10 个货架，货架尺寸为长 2.5 米、宽 1 米、高 3 米，巷道宽度 3 米。

import bpy # 基础参数 rack_length = 2.5 rack_width = 1.0 rack_height = 3.0 aisle_width = 3.0 racks_per_side = 10 aisle_count = 4 # 创建单个货架的函数 def create_rack(name, location): bpy.ops.mesh.primitive_cube_add(size=1, location=location) rack = bpy.context.active_object rack.name = name rack.scale = (rack_length / 2, rack_width / 2, rack_height / 2) bpy.ops.object.transform_apply(scale=True) return rack # 批量生成 for aisle in range(aisle_count): aisle_x = aisle * (rack_length * 2 + aisle_width) for side in range(2): side_offset = (rack_width + aisle_width / 2) * (1 if side == 0 else -1) for i in range(racks_per_side): rack_name = f"Rack_{chr(65 + aisle)}{side + 1}{i + 1:02d}" rack_y = i * (rack_width + 0.2) location = (aisle_x, rack_y + side_offset, rack_height / 2) create_rack(rack_name, location)

这段脚本跑完，80 个货架就位，命名规则是Rack_A101到Rack_D210。其中A到D是巷道编号，1和2是巷道两侧，后两位是货架序号。

实操心得：脚本里的0.2是货架之间的间隙，实际项目中要根据消防通道要求调整。如果后端数据里的库位编号规则不同，改一下rack_name的拼接逻辑就行，不用重新摆模型。

4.2 导出 glTF 的参数设置

Blender 导出 glTF 的入口是File → Export → glTF 2.0。有几个参数直接影响前端加载效果。

格式选 glTF Binary (.glb)。相比 glTF Separate，glb 把模型、材质、贴图打包成一个文件，前端只需要加载一个资源，减少 HTTP 请求数。

勾选 +Y Up。Blender 是 Z 轴向上，Three.js 是 Y 轴向上。勾选这个选项后，导出时自动做坐标转换，前端不需要再旋转模型。

不勾选 Apply Modifiers。如果模型上还有未应用的修改器，导出前先手动应用。勾选这个选项虽然方便，但有时会导致导出结果与 Blender 视图不一致。

压缩选 Draco。Draco 是谷歌开源的几何压缩算法，能把模型体积压到原来的三分之一左右。代价是前端需要加载 Draco 解码器，增加约 200KB 的额外资源。对于货架数量多的场景，这个交换是值得的。

导出后的 glb 文件建议放在public/models/目录下，Vue 3 项目里通过import或fetch加载。

4.3 Three.js 场景初始化与模型加载

Vue 3 组件里初始化 Three.js 场景，核心是把场景、相机、渲染器的创建放在onMounted里，把渲染循环放在requestAnimationFrame里。

import * as THREE from 'three'; import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader'; import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader'; const scene = new THREE.Scene(); const camera = new THREE.PerspectiveCamera(45, width / height, 0.1, 1000); camera.position.set(30, 25, 30); camera.lookAt(0, 0, 0); const renderer = new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(width, height); renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)); const dracoLoader = new DRACOLoader(); dracoLoader.setDecoderPath('/draco/'); const gltfLoader = new GLTFLoader(); gltfLoader.setDRACOLoader(dracoLoader); gltfLoader.load('/models/warehouse.glb', (gltf) => { scene.add(gltf.scene); buildObjectMap(gltf.scene); });

setPixelRatio限制在 2 以内，是因为高分屏上像素比可能到 3 甚至 4，渲染压力翻倍但肉眼几乎看不出差别。

4.4 货架状态切换的材质方案

货架状态通常有三种：空置、占用、锁定。最直观的表现方式是颜色区分：空置用灰色，占用用蓝色，锁定用橙色。

实现方式不是给每个货架单独创建材质，而是预先创建三个共享材质：

const statusMaterials = { empty: new THREE.MeshStandardMaterial({ color: 0x888888 }), occupied: new THREE.MeshStandardMaterial({ color: 0x2b7de9 }), locked: new THREE.MeshStandardMaterial({ color: 0xe98b2b }) }; function updateRackStatus(rackId, status) { const rack = objectMap.get(rackId); if (rack) { rack.material = statusMaterials[status]; } }

共享材质的好处是内存占用低，切换时只是换引用，不需要重新编译着色器。缺点是如果某个货架需要单独调色，就不能用共享材质了。实际项目中，状态颜色统一是常态，个别高亮可以用额外的轮廓线或发光效果实现。

4.5 AGV 路径动画的实现

AGV 的运动轨迹通常是一系列路径点。前端拿到路径点数组后，用CatmullRomCurve3生成平滑曲线，再根据时间参数取曲线上的点。

const pathPoints = [ new THREE.Vector3(0, 0, 0), new THREE.Vector3(10, 0, 0), new THREE.Vector3(10, 0, 15), new THREE.Vector3(0, 0, 15) ]; const curve = new THREE.CatmullRomCurve3(pathPoints); const progress = { t: 0 }; function animateAGV() { progress.t += 0.002; if (progress.t > 1) progress.t = 0; const point = curve.getPoint(progress.t); agv.position.copy(point); const tangent = curve.getTangent(progress.t); agv.lookAt(point.clone().add(tangent)); }

lookAt让 AGV 的车头始终朝向运动方向。如果 AGV 模型的初始朝向不是+Z，需要在lookAt之后额外旋转。

注意：CatmullRomCurve3生成的曲线会穿过所有路径点，但转弯处可能超出巷道边界。如果巷道很窄，建议用LineCurve3分段直线，转弯处用圆弧过渡，控制更精确。

5. 常见问题与排查技巧实录

5.1 模型加载后位置偏移或缩放异常

这是最高频的问题。表现是模型加载后不在预期位置，或者大小与设计不符。

排查顺序：

1. 检查 Blender 导出时是否勾选了+Y Up。没勾选的话，模型会躺倒。
2. 检查 Blender 场景单位是否为米。单位是厘米的话，导出后模型会放大 100 倍。
3. 检查 Three.js 里是否对模型做了额外的scale或position设置。有时候代码里写了model.scale.set(0.01, 0.01, 0.01)是为了适配某个旧模型，换了新模型后忘了删。

我遇到过一次，模型在 Blender 里看是正常的，导出后前端显示只有指甲盖大小。查了半天发现是 Blender 场景单位被设成了毫米，导出时没有做单位转换。改成米之后问题消失。

5.2 帧率低、操作卡顿

帧率问题的排查可以用 Chrome DevTools 的 Performance 面板录一段，看时间花在哪里。

常见原因和对策：

如果货架数量超过 500 个，建议用InstancedMesh。所有货架共享一个几何体和材质，通过实例矩阵控制位置，draw call 从 500 降到 1。代价是每个实例不能单独改材质，状态切换需要用实例颜色属性来实现。

5.3 Blender MCP 连接不稳定

MCP 连接断开的典型表现是：Antigravity 里发指令没反应，或者提示连接超时。

处理步骤：

1. 确认 Blender 的 MCP 面板显示Running状态。如果是Stopped，点击Start Server。
2. 确认端口没有被其他程序占用。在终端执行lsof -i :9876（macOS/Linux）或netstat -ano | findstr 9876（Windows）查看。
3. 如果 Antigravity 和 Blender 不在同一台机器上，确认防火墙允许该端口通信。
4. 重启 Blender 和 Antigravity。MCP 连接偶尔会因为长时间空闲而断开，重启是最快的恢复方式。

实操心得：在长时间建模过程中，建议每隔一段时间手动在 Antigravity 里发一个简单指令（比如“列出当前场景所有对象”），确认连接仍然活跃。这样比等到需要批量操作时才发现断连要好。

5.4 数据更新后模型状态不变化

数据推送到前端了，但模型颜色没变。排查思路：

1. 在updateRackStatus函数里打console.log，确认函数被调用了。
2. 确认objectMap.get(rackId)返回的不是undefined。如果是，说明业务 ID 与模型userData.bizId不匹配。
3. 确认材质切换后是否需要material.needsUpdate = true。共享材质切换引用不需要，但如果是修改材质属性则需要。
4. 确认渲染循环在运行。如果requestAnimationFrame被意外停止，画面不会刷新。

最常见的原因是 ID 不匹配。后端传的是"A-01"，模型里存的是"A01"，差一个横杠就找不到。建议在项目初期就定好 ID 格式，前后端统一。

5.5 常见问题速查表

6. 资产生产阶段的效率技巧

6.1 用 Antigravity 生成 Blender 脚本的提示词写法

Antigravity 生成脚本的质量，很大程度上取决于提示词是否具体。模糊的提示词比如“帮我生成货架”，得到的结果往往不能用。有效的提示词要包含以下要素：

• 对象数量与排列方式（几行几列、间距多少）
• 尺寸参数（长宽高，单位米）
• 命名规则（前缀、序号格式）
• 特殊要求（朝向、材质、是否需要合并）

举个例子，我实际用过的一条提示词是：“在 Blender 里生成 4 条巷道，每条巷道两侧各 10 个货架，货架尺寸 2.5x1x3 米，巷道宽 3 米，货架间距 0.2 米，命名格式 Rack_巷道字母+侧号+序号，序号两位补零，所有货架合并为一个对象。”

这条提示词生成的脚本基本一次通过，只需要微调一下坐标计算。如果只说“生成货架阵列”，得到的脚本大概率缺少命名规则和合并操作，还要手动补。

6.2 材质与贴图的轻量化策略

数字孪生场景里，材质复杂度对性能的影响不亚于面数。几个实用原则：

能用纯色就不用贴图。货架的金属灰、AGV 的黄色，直接用MeshStandardMaterial的color属性，不需要贴图。贴图只在有 logo、标识、纹理需求时使用。

贴图尺寸控制在 512 以内。数字孪生视角下，货架上的标签最多占屏幕几十个像素，1024 的贴图和 512 的贴图肉眼几乎看不出区别，但内存占用差四倍。

用 roughness 和 metalness 代替复杂光照。MeshStandardMaterial的这两个属性可以模拟大部分工业设备的质感，不需要额外的光照贴图。

6.3 场景组织与分组管理

Three.js 场景里的对象多了以后，用Group做分组管理，比全部平铺在 scene 下更清晰。

建议的分组方式：

• warehouseGroup：所有货架
• equipmentGroup：AGV、堆垛机、传送带
• structureGroup：地面、墙壁、立柱
• labelGroup：文字标签、指示牌

分组的好处是批量操作方便。比如要隐藏所有设备，直接equipmentGroup.visible = false，不需要遍历场景找设备对象。做相机聚焦时，也可以按组计算包围盒。

6.4 版本管理与资产迭代

Blender 源文件和导出的 glb 文件都要纳入版本管理。建议的目录结构：

project/ assets/ blender/ # Blender 源文件 warehouse_v1.blend warehouse_v2.blend models/ # 导出的 glb warehouse_v2.glb src/ three/ scene.js loader.js

每次修改 Blender 源文件后，导出的 glb 文件名带版本号，前端引用时明确指定版本。这样如果新版本有问题，可以快速回退到旧版本，不需要重新导出。

实操心得：glb 文件是二进制格式，Git diff 看不出变化。建议在提交时附一段简短的变更说明，比如“v2：增加 C 巷道货架，调整 AGV 路径点”。这样回溯时知道每个版本改了什么。

7. 从可视化到孪生的最后一公里

7.1 数据接口的设计约定

前端与后端的数据接口，建议用 WebSocket 而不是轮询。仓储设备状态变化频繁，轮询要么延迟高要么请求量大，WebSocket 推送更合适。

消息格式建议统一为：

{ "type": "rack_status", "timestamp": 1700000000000, "data": [ { "rackId": "A101", "status": "occupied" }, { "rackId": "A102", "status": "empty" } ] }

type区分消息类别，data是数组，支持批量更新。前端收到后遍历data，逐条调updateRackStatus。

7.2 状态同步的节流与批处理

如果后端推送频率很高（比如每秒 10 次），每次都触发材质切换会导致不必要的渲染开销。建议做一层节流：收集 100 毫秒内的所有更新，合并成一次场景刷新。

let pendingUpdates = []; let scheduled = false; function onDataReceived(updates) { pendingUpdates.push(...updates); if (!scheduled) { scheduled = true; setTimeout(flushUpdates, 100); } } function flushUpdates() { pendingUpdates.forEach(({ rackId, status }) => { updateRackStatus(rackId, status); }); pendingUpdates = []; scheduled = false; }

这样即使后端每秒推 10 次，前端实际刷新频率也只有 10 次每秒，但每次刷新处理的是合并后的数据，减少了重复的材质切换。

7.3 后续扩展方向

这个项目骨架搭好之后，可以往几个方向扩展：

增加设备动画。堆垛机的升降、传送带的运转，用AnimationMixer播放 glTF 里自带的动画，或者用代码控制对象位移。

接入实时视频流。在三维场景里嵌入监控画面，点击摄像头模型弹出视频窗口。这需要后端提供视频流地址，前端用VideoTexture或 HTML 叠加层实现。

做路径规划可视化。AGV 的任务路径用线条动态绘制，配合颜色区分优先级。这需要后端提供路径规划算法的输出结果。

支持多仓库切换。如果企业有多个仓库，可以在场景里做切换逻辑，加载不同的 glb 文件，共用同一套数据绑定代码。

我在实际项目里发现，第一版能把“模型加载 + 状态变色 + 设备移动”这三件事跑通，后面加功能就是在这个骨架上挂东西，不会推翻重来。最怕的是一开始追求大而全，结果每个模块都半成品，最后连演示都跑不起来。先把核心链路打通，再逐步丰富，是更稳妥的节奏。