我接手过不少企业官网升级的项目，大部分客户上来就说"想要一个高大上的官网"，但真要落地的时候往往发现，传统图文混排的页面撑不起"高科技感"这三个字。直到我们把全景、三维模型和内容管理凑到一块，做成了基于 krpano 1.22 + Vue3 + Three.js 的"沐智3D空间站 CMS"，这个方向才算真正跑通。它能解决一个非常现实的痛点：让企业官网不再是一堆平面海报的堆叠，而是变成一个可以漫游的3D空间——客户打开首页就能"走进"企业园区、展厅、甚至生产线，同时后台又能像维护普通文章一样随时改场景、换热点、更新产品信息。
这套方案适合谁？一个是做展厅、文旅、产业园、智能制造这类"有物理空间可展示"的企业网站，另一个是正在做Web3D数字化展示平台的开发者。全文我会把技术选型的理由、CMS数据模型怎么设计、krpano和Three.js怎么分工、常见坑怎么填都拆开讲，代码和配置直接抄，是我自己踩过一遍之后的完整复盘。
1. 需求背景：企业官网为什么需要"3D空间站"
1.1 传统官网的体验瓶颈
普通企业官网过去几年基本被做成了"公司简介+产品列表+联系方式"的模板，前端再花哨，本质上还是图片和文字的排列组合。用户进来后很难形成空间认知，尤其对于制造业、房地产、文旅类企业，客户想看的不是口号，而是"你们工厂长什么样、产线有多先进、展厅有什么亮点"。平面图册式的官网在这些场景下转化效率非常低。
我做过一个设备制造企业的案子，客户说他们的最大卖点是15000平米的智能车间，但官网头图只能放一张静态照片，用户根本感受不到车间的规模感。后来我们换成了全景漫游：入口页面就是车间实景，用户可以转头、可以点击产线上的热点，弹出对应设备的参数视频和PDF。这一个改动，让官网询盘转化率提升了大半，因为访客在进入销售对话前，已经"亲眼看过"车间了。
这个案例让我意识到，企业官网未来的方向不是做更多花哨的动画，而是把"真实场景还原给用户"。3D化、全景化不是炫技，是信息传达方式的升级。但企业客户又不可能天天找外包改网页，所以必须有一层CMS——把场景、热点、模型、图文内容都变成后台可配置的数据，内容人员自己就能维护。
1.2 "3D空间站"的定位与核心优势
"沐智3D空间站 CMS"不是一个单纯的全景播放器，也不是一个普通的后台管理系统，而是把两者合二为一的官网内容平台。核心思路是：每个页面可以挂载一个"空间"（空间站），空间内由全景场景、三维模型、热点标注共同组成，所有内容通过CMS数据驱动前端渲染。
听起来复杂，但实际对最终用户只有一个感受：官网能"走进去"了。管理员登录后台，可以新建一个"企业展厅"空间，上传几个全景图，在画面上拖拽添加热点，热点可以指向另一个全景场景、可以弹出一个产品详情弹窗、也可以跳转到一个Three.js加载的3D模型页面。整个流程不需要写一行代码，发布后前台官网实时生效。
这套方案的核心优势有三个：
- 沉浸式信息承载：全景负责"真实场景还原"，Three.js负责"抽象产品可视化"，两者互补，比纯图片高一个维度。
- 内容可运营：后台可视化编辑场景、热点、模型地址，企业市场部随时可以自己更新展厅内容，不再依赖开发排期。
- 技术栈统一：前端整体跑在 Vue3 里，krpano和Three.js都作为可调度的渲染引擎，路由、鉴权、接口请求、SEO，全部走一套工程体系，不会出现"全景页面一套代码、普通页面另一套代码"的割裂。
2. 技术选型：krpano + Vue3 + Three.js 三驾马车
2.1 为什么选 krpano 1.22 而不是纯 Three.js 做全景
全景漫游这个需求，理论上Three.js也能实现——加载一张全景贴图，套在一个球体上，再写一套射线检测做热点。第一版原型我也真这么干过，但做到后面发现工作量全花在"不是重点"的地方：热点点击的与动画交互、多场景之间的过渡效果、移动端陀螺仪的防抖处理、iOS上视频纹理的兼容……每一个都很磨人。
krpano 在这块是沉淀了十多年的成熟引擎，1.22 版本对WebGL渲染、移动端性能、热点动画系统都有比较完整的能力。它天然支持多场景跳转、补间动画、视频全景、自动巡航，而且配置文件用XML编写，一个全景项目的"内容"和"逻辑"分离得特别清楚。对做CMS来说，这反而是个优点——我甚至可以直接在后台生成XML片段，让krpano动态加载配置，内容更新就不用动前端代码。
但krpano也有明显短板：它虽然能做三维模型嵌入，但本质上还是"以全景为中心"的展示工具，对于需要自由操控的产品三维模型（比如旋转查看一台设备的每个部件）、复杂交互动画，并不是它的强项。这时候就需要Three.js补位。
我的分工原则是：看得见的环境用krpano，摸得着的物体用Three.js。举例来说，企业官网首页是一个园区全景漫游，用户点击某个车间的门，进入车间全景，再点击一台机器设备，此时弹层内用Three.js渲染这台机器的可交互三维模型，可以旋转、剖切、查看零件标注，两个引擎通过Vue3做状态中转，互不干扰。
2.2 Vue3 作为前端主框架的优势
Vue3在这里的价值是工程化和状态整合。krpano和Three.js本质上都是"渲染引擎"，它们各自有一套生命周期和事件机制，如果没有一个上层框架做统一调度，项目很快就会变成一团乱麻——全局面板挂在window上，回调函数散落各处，场景切换时资源无法回收。
我选择Vue3，核心看中三件事：
- 组合式API：把krpano实例、Three场景、CMS数据、UI状态按业务维度封装成多个composable（比如
usePano()、useModelViewer()），代码组织比Options API清爽太多，一个功能模块的代码能聚拢在一起。 - 响应式状态桥接：CMS下发场景配置 → 响应式数据变化 → 自动驱动krpano切换场景或更新热点，这个联动用Vue3的
watch写起来非常顺手。 - 周边生态成熟：Vite构建、Vue Router路由、Pinia状态管理、Element Plus后台UI，整套工程体系跑得很顺，招人也容易。
另外一个实际原因是Vue3对TypeScript支持更好。企业官网CMS这种项目，后台数据结构和3D场景配置项非常多，一个场景的config可能有七八十层嵌套，没有类型约束，维护半年后改字段就是灾难。用TS把"场景对象""热点对象""模型对象"这些类型定死，ide提示和运行时校验都能跟上。
2.3 Three.js 在方案中的定位与实践价值
在这个CMS里，Three.js不是用来替代krpano的，而是用来完成krpano做不好的"可交互三维物体展示"和"数据可视化"。
最典型的场景是产品展示。企业有一台大型设备，传统官网放几张图，用户看不清楚细节。我们后台可以配置一个"模型空间"，管理员上传GLB格式的三维模型文件（可由3D建模师从原始CAD数据转换而来），前台用Three.js加载，并提供旋转、缩放、剖切、爆炸图分解、标注气泡等交互。这些能力krpano想做会非常吃力，但对Three.js来说就是标准操作。
其次是数字孪生类的可视化页。比如把工厂生产线的实时数据做一个3D示意图，用Three.js渲染整个车间的简化模型，不同工位的设备根据接口数据改变颜色或触发动画。这类场景在全景图里没法实现，因为全景是"实景照片"，没法动态反映数据变化；而Three.js是"构建场景"，天然可以和数据绑定。
所以在"沐智3D空间站 CMS"里，Three.js是负责**"活的、动态的、可交互的三维内容"，krpano负责"真实的、沉浸式的、大面积的环境呈现"**。Vue3在上面做调度，CMS在下面做数据供给，四个层次关系非常清晰。
3. 系统架构与核心设计
3.1 分层架构：数据模型与渲染引擎解耦
整个系统从底层向上分五层，每一层只依赖下一层，不跨层调用：
- 存储层：MySQL/PostgreSQL保存场景配置、热点数据、模型文件索引、页面元信息。
- 接口层：RESTful API / JSON，输出给前端的是一份标准化的"空间配置对象"。
- CMS管理端：Vue3 + Element Plus实现的可视化编辑器，操作全景截图、拖拽热点、绑定跳转和弹窗。
- 前端运行时：Vue3应用，根据路由加载不同类型的空间页面，并初始化对应渲染引擎。
- 渲染引擎：krpano实例和Three.js场景，只负责渲染和交互反馈，不直接发请求，所有数据由Vue层注入。
这套架构里最关键的决策是：krpano和Three.js都不直接请求后端接口，而是由Vue层统一获取CMS数据后，把处理好的JSON对象"喂"给它们。好处很明显——换渲染引擎时不影响数据层；排查问题的时候，只要看数据有没有给对，就能确定问题出在渲染层还是内容层。
实际开发时我把一个空间页面定义为这样的配置对象（简化版）：
{ "sceneId": "factory_lobby", "engine": "krpano", "source": "/static/panos/factory_lobby/tour.xml", "hotspots": [ { "id": "hs_1", "type": "scene", "target": "workshop_a", "position": { "ath": 120, "atv": -10 }, "title": "进入A车间" }, { "id": "hs_2", "type": "product", "position": { "ath": 45, "atv": 15 }, "title": "查看智能机床", "action": "openModel", "modelUrl": "/static/models/cnc_machine.glb" } ] }前端拿到这份配置后，如果engine是krpano，就初始化全景；如果是three，就初始化模型场景。热点按钮的渲染交给Vue组件，krpano里的热点坐标和Vue里的DOM位置通过事件同步。这样做还有一个额外好处：SEO页面可以用同一份数据做预渲染，静态输出全景首屏图和热点说明文字，搜索引擎不会一片空白。
3.2 CMS内容模型：场景、热点、模型是怎么管理的
CMS后台把3D空间拆成了几个彼此关联的概念，对应后台的几个管理菜单：
- 空间（Space）：对应官网上的一个完整3D页面（如"企业展厅"）
- 场景（Scene）：一个空间内可以包含多个全景场景，场景之间通过热点跳转
- 热点（Hotspot）：挂在场景内的可点击标注，类型包括跳转场景、打开弹窗、加载模型、跳转链接
- 模型资产（Asset）：上传的GLB/GLTF三维模型文件，以及对应的缩略图和标注点配置
这个关系其实就是"空间 1—N 场景，场景 1—N 热点，热点 1—1 模型资产"。后台做成了嵌套关系模型：编辑一个空间时，左侧是场景列表，中间是全景预览画面，右侧是当前场景的热点配置面板。内容人员点击全景画面上的某个位置，就能新增一个热点，属性面板里填写标题、选择动作类型、选择目标场景或模型文件，保存后整个空间的配置以JSON形式落库，前台API直接返回这份JSON。
热点位置的编辑是个细节，krpano 用的是ath/atv球面坐标，纯靠手动填数字不现实。我在后台嵌入了一个轻量的krpano播放器作为编辑器预览，内容人员在预览画面里直接用鼠标点击目标位置，前端捕获ath/atv值回填到表单，这样就不需要用户理解坐标体系了。同理，Three.js模型上的标注点，后台用的是一个正交投影的缩略图编辑器，用户点击模型缩略图上的位置，换算成模型空间坐标存下来，虽然精度有限，但对大多数企业展示场景足够用。
3.3 前端性能与资源加载策略
3D官网最怕两件事：首屏加载太慢和低端设备卡顿。这块必须从架构层面就设计好。
资源加载采用"按需加载 + 分级加载"策略。首屏只加载当前场景对应的一张降采样全景图（比如宽度2048像素）和基础UI代码，用户进入场景后再用setTimeout或空闲时加载原始分辨率全景图和预加载相邻场景缩略图。krpano 的preload属性可以控制，也可以用它的image.already-loaded事件做手动控制。
Three.js这边采用路由级代码分割：只有访问/model/:id页面时才动态加载three相关模块和模型文件，避免拖慢全景页面的加载速度。模型文件本身也要做压缩——GLB格式首选，用gltf-pipeline做网格压缩和纹理压缩，能缩掉六到七成体积。我遇到过客户直接扔过来一个200MB的FBX模型，如果不在上传环节做转换校验，前端根本跑不动。
机型适配在架构层用"降级方案"解决。全景页最低保证一屏静态全景图可用，如果用户浏览器不支持WebGL或性能不足，Vue层检测到后自动隐藏krpano交互按钮，保留纯观看模式；Three.js模型页则显示一个预处理好的多角度GIF或视频代替3D交互。这套降级逻辑写成通用方法，在后台上传模型时先生成好降级资源，避免运行时才去处理。
4. 实操过程：从零搭建一个3D官网模块
4.1 环境准备与项目初始化
项目采用 Vite + Vue3 + TypeScript 初始化，这一步几乎所有Vue3项目都一样，没什么特殊之处：
npm create vite@latest mbz-space-cms -- --template vue-ts cd mbz-space-cms npm install装完之后我把目录结构按"引擎层/功能层"做了划分，避免不同渲染引擎的代码缠在一起：
src/ components/ pano/ # krpano 相关组件 viewer3d/ # Three.js 相关组件 ui/ # 热点气泡、弹窗等UI组件 composables/ usePano.ts # 封装krpano实例生命周期 useContext.ts # 全局空间上下文 useHotspot.ts # 热点交互逻辑 services/ api.ts # CMS接口请求 scene.ts # 场景配置转换 stores/ space.ts # Pinia状态 types/ space.ts # 空间/场景/热点类型定义krpano官方SDK需要单独安装。它不是一个npm包，而是发布包里的viewer目录，里面有krpano.js和对应的swf（Flash审核资源）、webgl播放器相关文件。我把它放在public/krpano/下，这样构建时原样拷贝到发布目录。需要注意的是，新版krpano虽然有JS API，但底层仍会检测运行环境，部署时必须确保krpano.js和插件文件在同一目录层级，否则会出现奇怪的加载失败。
4.2 在Vue3中嵌入krpano全景
嵌入方式上有两个选择：iframe嵌入官方示例，或者用krpano的JS接口直接挂载。我们一开始图省事用iframe，结果马上就遇到麻烦了——路由跳转和postMessage通信都能做，但热点弹层如果要在iframe外面显示会非常别扭，坐标对不齐，样式也难控制。最终方案是放弃iframe，用krpano提供的embedpano()方法，把它挂载到一个普通的DOM容器上。
封装后的核心逻辑在一个PanoViewer.vue组件里：
<script setup lang="ts"> import { onMounted, onBeforeUnmount, ref, watch } from 'vue' import type { PanoConfig, Hotspot } from '@/types/space' const props = defineProps<{ config: PanoConfig }>() const emit = defineEmits(['scene-change', 'hotspot-click']) const container = ref<HTMLElement | null>(null) interface KrpanoInstance { call: (code: string) => void get: (name: string) => unknown set: (name: string, value: unknown) => void addEventListener: (event: string, fn: (...args: unknown[]) => void) => void } let krpano: KrpanoInstance | null = null let currentScene = '' function initKrpano() { if (!window.embedpano) return const state: Record<string, unknown> = {} window.embedpano({ xml: getKrpanoXml(props.config), target: container.value, html5: 'auto', mobilescale: 1, passQueryParameters: true, onready: (instance: KrpanoInstance) => { krpano = instance bindEvents() }, onerror: (error: unknown) => { console.error('krpano初始化失败', error) } }) // 手动保存实例，后续事件 } function bindEvents() { krpano?.addEventListener('sceneloaded', (sceneId: unknown) => { currentScene = String(sceneId) emit('scene-change', currentScene) }) } </script>这里关键点有两个：一是embedpano的onready回调拿到的实例其实就是window.krpano的副本，建议立刻保存到组件内部变量，避免后续全局查找；二是krpano事件模型是"注册回调"，但不同版本API细节有变化，1.22里面addEventListener监听sceneloaded事件能拿到场景id，这在实际项目中用来和Vue路由状态同步特别方便。
4.3 热点配置与krpano-Vue双向通信
热点的渲染方式我建议分成两层：krpano负责热点在球面上的坐标定位和透镜变形，Vue负责热点视觉元素和DOM交互。这样写的好处是热点样式可以完全用CSS控制，做出悬浮动画、波纹、渐变等效果，不会受krpano自带热点皮肤限制。
实现时，我在全景初始化后，通过krpano.call()动态创建一批空的热点对象，只设置坐标和尺寸，然后监听它们的onclick事件，把点击事件桥接到Vue组件的emit上。Vue侧根据热点数据渲染一个固定在屏幕上的悬浮层，通过每个热点实时的ath/atv球面坐标投影成屏幕坐标后更新位置。
投影坐标是这里最需要细心的地方。简单方案是让krpano的每个热点在click时上报自己的屏幕坐标，但更稳的是用ath/atv加上当前hlookat/vlookat视场角做数学换算。我在项目里写了一个projectToScreen工具函数，基于球面坐标转屏幕坐标的公式实现。虽然不能做到100%像素级准确，但在1080p分辨率下误差在可接受范围，热点标签可以稳稳跟随物体移动。
export function projectToScreen( ath: number, atv: number, hlookat: number, vlookat: number, hfov: number, width: number, height: number ): { x: number; y: number } { const d = ath - hlookat const x = width / 2 + (d / hfov) * width const y = height / 2 - (atv - vlookat) / hfov * height return { x, y } }热点点击后产生的动作（打开弹层、跳转场景、加载模型）完全由Vue业务层决定，后台配置的action字段就是指令，Vue组件根据指令执行对应操作。这样做还有一个好处：当用户点击"查看模型"类型的热点时，弹层内加载的不一定非是Three.js渲染的模型，也可以是视频或图文介绍，CMS配什么就是什么，扩展性很强。
4.4 Three.js模型展示与场景联动
Three.js的部分我封装了一个ModelViewer.vue组件，用来渲染可交互的产品模型。加载模型、设置相机、添加灯光、拖拽控制是基础能力；针对企业官网的场景，我重点加了两个功能：标注点系统和模型剖切。
标注点系统对接后台配置的标注数据。模型加载完成后，根据每个标注点的模型空间坐标，用一个小球或图标标记，再通过Vector3.project(camera)映射到屏幕坐标，渲染对应的文字标签。实际实现和全景里的热点投影思路一致，只是坐标系不同。
function updateMarkerPositions() { markers.forEach((marker) => { const pos = marker.worldPosition.clone() pos.project(camera.value) const x = (pos.x * 0.5 + 0.5) * containerWidth const y = (-pos.y * 0.5 + 0.5) * containerHeight marker.dom.style.transform = `translate(${x}px, ${y}px)` }) requestAnimationFrame(updateMarkerPositions) }模型剖切是制造类企业特别喜欢的功能：用一个平面裁剪模型，用户可以沿着模型的切割面看到内部结构。Three.js实现剖切很简单，给一个Plane几何体，用一个独立的材质渲染裁切效果，配合animations实现剖切面动画。但要注意半透明模型和裁切的渲染顺序问题，需要设置depthWrite: false避免透明面遮挡。
场景联动指的是：从全景里点击某个设备热点 → 切换模型视图 → 用户在模型视图操作完后 → 返回全景，全景状态（视野角度、场景位置）要能恢复。这个状态我们放在Pinia里，进入模型视图前把当前场景ID和相机状态存起来，返回时再通过krpano的loadscene和lookat指令恢复。实测下来体验很流畅，用户感觉是"走进一架设备再退出来"，而不是跳去了另一个页面。
4.5 CMS后台的关键实现思路
后台的核心任务是"所见即所得"地编辑3D空间。后台技术栈同样用Vue3，前端实现一个可交互的预览画布：左半边是krpano播放器，右半边是热点属性和场景配置表单，前端直接调用krpano API让用户在预览画面里点选位置、查看热点，保存时把配置聚合为JSON提交到后端。
比较难做的是"热点的拖拽微调"。预览里用户点了一个位置创建热点后，如果想微调，需要在播放器里捕捉到鼠标拖拽事件，再反向把新的屏幕坐标转换成ath/atv并写回表单和场景。我封装了一个拖拽指令，通过计算鼠标位移与当前视场角的比例来更新坐标，灵敏度调了好几版，最终效果是拖起来跟拽普通DOM差不多，内容编辑员半小时就能上手。
后台还会做一个"发布预览"功能：草稿状态的空间在未发布前，通过带token的预览链接访问，只有被授权的人能看到。这块实现主要靠后端在返回空间配置时加上status字段，前端根据登录态和路由类型决定是渲染正式内容还是草稿内容，逻辑不复杂，但能大幅提升内容团队的工作效率。
5. 常见问题与排查技巧实录
5.1 krpano 与 Vue Router 的协调冲突
最典型的问题是路由切换后，重新进入全景页面，krpano 容器里残留之前的canvas或webgl上下文，导致初始化失败或白屏。我们遇到的报错是embedpano执行多次后控制台出现 "Cannot read properties of null (reading 'appendChild')"。
原因其实就是销毁没有做干净。PanoViewer.vue的onBeforeUnmount里没有调用krpano的销毁接口。解决办法是记住实例引用，明确调用它的remove()方法或destroy()。对于1.22，可以直接krpano.call("remove")，然后清空容器DOM内容。同时要注意Vue组件的key不该复用——每次进入页面应该新建组件实例，而不是复用旧的。
我封装了一个usePanocomposable，在组件卸载时统一执行清理，实测拿这个去反复切换路由十几次，没有再出现白屏。
5.2 Three.js 模型加载 404 和跨域问题
项目上线后遇到过几次模型404，排查后基本都是后台资源上传时路径存储不规范。CMS上传模型时生成的文件名用了中文或特殊字符，部署到Nginx后URL编码不匹配，导致前端请求失败。我的修正方案是上传时统一重命名为UUID格式，原文件名只存数据库作为展示名，彻底避开中文路径问题。
跨域问题主要出现在模型引用了外部纹理（比如GLTF格式引用了外部bin和jpg）的情况下。开发环境Vite代理能解决，生产环境如果模型文件和网页不在同一个域，需要给文件服务配置 CORS 头。我一般在Nginx层统一加：
location /static/models/ { add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Headers *; add_header Access-Control-Allow-Methods GET; if ($request_method = 'OPTIONS') { return 204; } }5.3 移动端性能与触摸体验优化
全景在手机上容易发热和卡顿，这在低端安卓机上特别明显。krpano的配置里可以限制渲染分辨率，比如把idp的image设为移动端专用较低分辨率版本，或者开启mobile_fov_limit限制灵敏度和最大视角。我自己常用的设置是：
<display details="16" fovmin="60" fovmax="100" /> <mobile_fov_limit hlookatmin="-90" hlookatmax="90" vlookatmin="-30" vlookatmax="30" />同时移动端点击热点的误触率比PC高，我建议把热点点击响应区域做得比视觉元素大一圈（比如视觉图标24px，点击区域48px），并在热点组件上做touchmove与click的区分——用户拖动全景时的位移超过一定像素就不触发点击，避免想转视角结果弹出了产品详情。
Three.js模型页在移动端优先降低像素比：renderer.setPixelRatio(Math.min(window.devicePixelRatio, 1.5))，再配合renderer.shadowMap.enabled = false（模型展示场景一般不需要实时阴影，烘焙贴图就够了），帧率能明显提升。
5.4 CMS字段变更引发的渲染异常
这类问题最容易在后期维护阶段爆发：后台增加了一个新的热点类型，但老场景配置里没有这个字段，前端渲染时undefined没有兜底，导致整个热点渲染报错，甚至全景页面白屏。排查时往往很被动，因为问题不在前端逻辑，而是数据兼容性。
我把前端的数据解析做成了"防御式"写法，组件内所有从配置里读取的可选字段都加上默认值；同时后端API在多返回一份schemaVersion字段，当前端发现版本低于期望值时不直接渲染，而是提示"场景配置需要升级，请联系管理员"。上线后这种问题少了很多，至少不会以白屏的形式出现。
还有一个容易被忽略的细节：krpano 场景之间的 if（条件）判断和Vue模板里的v-if不完全一致，如果热点配置里的target指向了不存在的场景ID，krpano跳转会静默失败。我在发布接口里加了一道校验，遍历所有热点，检查目标场景ID是否在当前空间范围内，有错误直接阻止发布并标注位置，省去了后续很多奇怪问题。
6. 经验总结与后续扩展方向
做这套方案踩过几次坑之后，我的体会是：3D官网项目的核心瓶颈不在技术，而在内容生产和管理。全景图拍摄、模型制作、热点打标，这些内容生产环节如果效率低，整个项目就会卡在那里。CMS的意义就是把这套内容生产流程产品化，让市场部、展厅运营方的人能自己上手，而不是每次改热点都要找开发改XML。
后续可以扩展的方向有三个。第一个是接入更多内容类型，比如在场景里嵌入视频作为热点动作，或者把Three.js模型展示升级成支持动画播放和材质切换的轻量交互。第二个是构建工具链，在后台增加批量导入功能，比如客户有一批全景图，直接拖进来按命名规则自动生成多个场景，大幅降低初始搭建成本。第三个是数据统计，记录用户在3D空间里的漫游路径、热点点击热力图，帮企业了解访客最关注哪个展区哪个产品，这个数据对市场决策非常有价值。
如果你也在考虑做类似的企业3D官网，我建议先不要追求大而全，从一两个核心场景跑通全链路——CMS能编辑、前台能展示、移动端能看、后台能配热点，这个最小闭环先跑起来，再逐步丰富交互形式。架构上保持渲染引擎和CMS解耦，后面想换更高级的技术方案也能平滑过渡。
