用 Three.js 构建数字孪生平台：架构与工程实践

先明确数字孪生的任务边界

数字孪生不是一个更大的三维模型。它应服务具体任务，例如人员定位、设备监控、园区巡检、仓储调度或应急指挥。任务决定需要加载哪些模型、数据更新多快、用户可以执行什么操作，也决定平台是否真的需要照片级效果。

项目开始时可以列出关键用户路径：搜索某台设备、切换到所在楼层、查看实时状态、回放历史数据、处理告警。之后再据此设计三维 API 和界面，而不是围绕场景特效组织代码。

推荐的五层架构

1. 渲染与场景层
   封装 renderer、scene、camera、controls、选取、剖切、后处理与渲染循环。
2. 资产与空间层
   管理 glTF、3D Tiles、纹理、楼层树、空间索引、坐标转换与资源生命周期。
3. 孪生对象层
   用稳定 ID 描述人员、设备、建筑和区域，将业务对象与场景节点关联。
4. 数据与事件层
   接入 REST、WebSocket、MQTT 等数据，处理快照、增量、缓存、订阅与事件规则。
5. 应用界面层
   提供搜索、筛选、对象详情、告警、时间轴和权限可见的业务操作。

这些层并不意味着必须拆成五个独立仓库，但依赖方向要清晰：界面调用场景能力，数据更新孪生对象，孪生对象再驱动可视表达。渲染循环不应直接访问页面组件状态或解析业务协议。

三维引擎应该暴露哪些能力

模型资产流水线

原始 BIM、CAD、倾斜摄影和手工模型不能直接以同一方式进入浏览器。应建立资产转换流程，完成坐标校准、几何清理、材质合并、纹理压缩、层级拆分和元数据索引，并为输出结果生成版本号与资源清单。

glTF 与 3D Tiles 如何选择

独立设备、室内小场景和需要动画的模型适合 glTF；超大园区、城市或需要按视距流式加载的内容适合 3D Tiles。实际平台可以同时使用两者：地形和建筑群用 Tiles，重点设备与动态对象用 glTF 或实例化几何。

资源生命周期必须可控

Three.js 从场景移除对象并不会自动释放 GPU 资源。卸载时要正确 dispose 几何、材质、纹理和渲染目标；共享资源则需要引用计数或统一缓存，避免释放后影响其他对象。

实时数据怎样驱动场景

实时消息先进入状态仓库，按对象 ID 合并成最新快照，再由表现层将状态映射为位置、颜色、动画或标签。这样即使更换数据协议，场景 API 也不需要跟着变化。

数据频率和渲染频率应解耦。高频点位采用插值，低频传感器仅在值变化时更新，告警通过事件触发。大量对象可按可见性、距离和重要程度设置不同刷新频率。

性能预算从第一天开始

• 给首屏资源、三角面、Draw Call、纹理、内存和帧时间设置可测量预算。
• 使用按需渲染；静态场景没有交互与数据更新时，无须持续满帧刷新。
• 对重复对象使用实例化，对标签使用聚合、可见性筛选和复用。
• 将重解析、几何解码和空间计算移到 Worker，避免长任务阻塞交互。
• 真实测试集应包含模型加载、快速切层、对象搜索和高峰实时数据。

让平台可以长期迭代

为场景 API、资产清单和孪生对象定义版本；记录模型版本与业务绑定关系；用回归视点检查渲染结果；在自动化测试中覆盖坐标转换、状态映射和资源释放。对于依赖 Three.js 内部实现的扩展，应隔离在适配层，降低升级成本。

同时保留浏览器能力降级方案。低性能设备可降低像素比、关闭阴影与后处理、限制可见范围；WebGL 不可用或资源加载失败时，界面应给出明确提示和恢复操作。

从原型到平台的实施顺序

1. 验证核心任务
   用一个真实楼层和一类实时对象跑通用户路径。
2. 稳定空间基准
   确定坐标、楼层、对象 ID 和模型版本规则。
3. 建立引擎边界
   把场景能力封装为接口，拆开业务协议与渲染实现。
4. 扩展资产和数据
   逐步接入更多模型、定位、设备与业务系统。
5. 补齐治理能力
   加入权限、审计、监控、性能预算和版本回滚。