企业官网建设流程全解析

简介：基于three.js构建的Web端VR虚拟展厅完整工程包，面向具备JavaScript基础、希望掌握WebGL三维渲染与虚拟漫游开发的前端工程师及3D学习者。项目利用three.js与WebGL技术，在浏览器中实现无需插件的硬件加速3D渲染，并通过VR技术打造可自由探索的360度沉浸式漫游空间，涵盖展厅场景、房间导引、展品展示与交互控制等完整环节。压缩包共89个文件、约48.32MB，其中10个js文件承担场景搭建、模型加载与交互逻辑，74个png图片覆盖展厅地板、墙面、展品及导引按钮等纹理素材，另有2个html入口页面、1个mp4演示视频、css样式及OBJ模型等辅助资源，目录按模块组织，便于按需查阅。目前已有718人学习下载。深入拆解源码，可以完整梳理three.js场景构建、光照调节、OBJ模型导入、VR模式适配及多房间漫游的实现思路，是入门Web端虚拟展示开发的优质实战参考。 这个项目的压缩包名字叫 three.js-VR展厅.zip，是我把一个线上虚拟展厅项目整理完之后，顺手打成压缩包分享给朋友的那一版。拆开这个包，里面不是那种还要装依赖、配环境、跑构建的工程模板，而是一个真正解压后就能直接用的 WebVR 页面：桌面端可以用鼠标环视展厅，手机端可以转动设备切换视角，接上 VR 设备后能进入沉浸式漫游模式，整个过程没有依赖 Node.js，也不需要安装任何桌面软件。

这个项目对我来说最大的价值是：它证明了 three.js 做轻量级 VR 展厅完全可行，而且可以做得非常“轻”。整个包压缩后不到 100MB，包含展厅场景、展品模型、贴图资源、粒子特效和 VR 交互逻辑。不少朋友拿到压缩包后，问得最多的三个问题是：这个怎么跑起来？模型资源怎么优化这么小？VR 模式到底怎么进？这篇文章我会从项目整体设计、核心模块实现、zip 在项目里的正确用法、以及实际踩过的坑这几个维度，把整个项目完整拆开讲一遍。想用 three.js 做 VR 展示、又不想被工程化流程卡住的朋友，可以直接参考这套方案。

1. 这个VR展厅项目到底做了什么

1.1 项目定位与最终效果

先说说这个展厅的定位。它不是那种数据大屏类的可视化项目，也不是纯展示单一模型的场景，而是一个有一定空间叙事感的虚拟展览空间。整个展厅采用类似美术馆的回字形动线，中央是一个大尺度的动态粒子装置，四周布置了多个展品台，每个展品台对应一件三维模型。用户进入展厅后，可以先在中央参观粒子装置，再沿着动线逐个浏览展品，每个展品点击后会弹出信息面板，展示名称和介绍文字。

技术实现上，场景使用 three.js 构建，采用 WebGL 渲染。普通浏览器环境里，我使用 OrbitControls 配合键盘和鼠标实现桌面端的自由视角；手机端通过设备方向传感器进行视角旋转；接入 VR 设备后，通过 WebXR API 进入沉浸模式，使用手柄射线进行交互选择。整个项目的核心逻辑只有一个主文件，其他资源全部放在 assets 目录下，这也让最终打压缩包分发变得非常方便。

这个项目适合谁参考？如果你正在做毕业设计、个人作品集、小型商业展示，或者只是单纯想体验一下 three.js 的 VR 能力，那么这个项目的结构和技术路线可以直接抄作业。它不要求你懂复杂的图形学原理，只需要基本的 JavaScript 和三维空间概念，剩下的代码逻辑并不复杂。

1.2 技术选型：为什么是 three.js

在开始写代码之前，我其实在 three.js 和 Unity WebGL 之间犹豫过一阵。Unity WebGL 做 VR 展厅的优势在于可视化编辑和现成的物理引擎，但有一个让我很难接受的问题：构建产物太大。一个简单的展厅场景，Unity WebGL 的加载包经常在几十 MB 到上百 MB 之间，再加上浏览器端的 WebGL 兼容性处理，首屏加载体验非常差。而且在非 VR 环境里，Unity WebGL 做 UI 交互需要额外引入 UI 框架，复杂度远超 three.js。

three.js 的优势在于颗粒度足够细、链路足够短。它的整个渲染管线是透明的：场景、相机、渲染器、光源、模型加载器，每个环节都清晰可控。你不需要像 Unity 那样处理繁重的工程导入流程，用 script 标签引入 three.js 核心库和几个扩展模块，十几行代码就能搭出一个可交互的三维场景。更关键的是，three.js 对 WebXR 的支持很完善，VRButton 模块可以一键启用 VR 模式，不需要写底层 WebXR 的冗长样板代码。

Flutter、CSS 3D 这类方案我也考虑过。CSS 3D 做简单的卡片翻转没问题，但做不了 PBR 材质、动态阴影和粒子系统，视觉上限太低。Flutter 的 3D 生态目前还比较初级，性能也不如 WebGL。综合下来，three.js 是 Web 端 VR 展示场景里最均衡的选择。

1.3 zip 分发方案带来的性价比

这个项目最早是放在本地服务器上跑的，后来有朋友说想拿去看效果，我就把整个目录压缩成一个 zip 发过去。没想到“three.js-VR展厅.zip”这个文件反而比项目本身更受关注。

压缩包在最开始有将近 300MB，主要是贴图资源和几个高模展品太大。我后来花了半天时间优化资源，把所有贴图转成 WebP、展品模型换成带 Draco 压缩的 GLB 格式，最终压缩包降到了 98MB，在局域网环境下传输基本无感。这个优化过程本身也是项目的一部分——在 Web 端做 VR 展示，性能预算必须一开始就卡死，否则后续优化会非常痛苦。

2. 核心功能模块拆解与实现细节

2.1 展厅空间与动线设计

展厅的空间结构是整个项目的骨架。我采用的是回字形布局：中央是半径 5 米的圆形展台，放置粒子装置；四周墙壁按 90 度间隔布置四个展品台，每个展品台与墙面保持 2 米距离，确保观展动线流畅，不会出现视角遮挡。地面使用大尺寸的浅色材质，墙面使用略带纹理的灰色，整体色调偏冷，配合暖色聚光灯，营造安静的展览氛围。

技术细节上，展厅地面和墙面都是用 PlaneGeometry 加 MeshStandardMaterial 实现的。这里有一个经验：StandardMaterial 配合环境贴图才能呈现真实的质感，如果只加灯光，材质看起来会像塑料。我使用的是 three.js 自带的 RoomEnvironment 生成器，通过 PMREMGenerator 生成环境贴图，效果比手动调整灯光参数要自然得多。

动线设计方面，我在每个展品台前设置了一个相机注视点。桌面端用户靠近展品台时，视角会自动平缓地转向展品中心。这个逻辑用 OrbitControls 的 target 插值实现，每一帧根据用户当前位置和最近展品台的相对距离计算是否需要调整视角，避免了生硬的视角跳转。VR 模式下这个逻辑会关闭，因为 VR 中强制控制相机方向会让用户产生强烈的眩晕感，必须把控制权完全交给用户。

2.2 模型与贴图资源处理

展品模型的处理是项目前期最耗时的一环。最初的模型是从 SketchFab 上下载的 FBX 格式，单个文件动辄几十 MB，且材质使用了大量高分辨率贴图。在 Web 端直接加载这种模型，大概率会白屏或者卡死。我最终的方案是：所有模型统一转成 GLB 格式，使用 glTF-Transform 工具进行网格精简，然后开启 Draco 压缩。

这里补充一个模型格式对比，方便新手做选择：

以中央展台的一个汽车模型为例，原始 FBX 是 46MB，转换成 GLB 后降至 28MB，开启 Draco 压缩后只剩 9MB，视觉细节基本看不出差别。这种体积控制对于 Web 端 VR 项目极其重要，因为移动端浏览器对 GPU 内存有限制，体积过大的模型极容易触发浏览器崩溃。

贴图方面，我坚持一个原则：单张贴图不超过 2K，能用 JPEG/WebP 就不用 PNG。展厅里的地面和墙面贴图，我做了重复纹理平铺，用 512x512 的小图也能达到较好的视觉效果。透明贴图（比如展品标签）才使用 PNG 格式，避免透明通道信息丢失。

2.3 中央粒子装置的动态效果

展厅中央的粒子装置是项目的视觉核心。这个装置本质上是 three.js 的 Points 系统，共使用 8000 个粒子，每个粒子在每一帧根据三角函数计算其位置偏移，形成类似玫瑰花瓣缓慢绽放的流动感。

实现上，我创建了一个 BufferGeometry，预先分配 8000 个粒子的初始位置和颜色。粒子的运动逻辑放在 requestAnimationFrame 循环里，通过一个全局时间变量 t 控制：

const positions = geometry.attributes.position.array; for (let i = 0; i < count; i++) { const angle = i * 0.01; const radius = 2 + Math.sin(t * 0.5 + i * 0.01) * 1.5; positions[i * 3] = Math.cos(angle) * radius; positions[i * 3 + 1] = Math.sin(t * 0.8 + i * 0.02) * 1.2; positions[i * 3 + 2] = Math.sin(angle) * radius; } geometry.attributes.position.needsUpdate = true;

需要特别注意的是：粒子数量不建议超过 10000。8000 粒子在桌面端可以保持 60 帧，在移动端大约 40 帧左右，再增加粒子数量性能会断崖式下降。另外，粒子材质我使用 AdditiveBlending 叠加混合模式，关闭深度写入，这样粒子在重叠区域会产生自然的发光效果，视觉上更接近“星光”或“花瓣”的感觉。

粒子装置的状态切换也是交互的一部分。默认状态下粒子缓慢旋转，当用户接近装置时，粒子运动速度会逐渐加快并改变颜色。这个逻辑是通过检测用户与装置中心的距离，在每一帧修改一个 speed 变量实现的。颜色变化则是对粒子颜色的 RGB 值做线性插值，从淡蓝色过渡到淡紫色。

2.4 VR模式适配与交互控制

VR 模式的接入，比我预想的要简单不少。three.js 从 r150 版本开始，官方提供了 VRButton 模块，只需要两行代码就能完成入口注入：

import { VRButton } from 'three/addons/webxr/VRButton.js'; renderer.xr.enabled = true; document.body.appendChild(VRButton.createButton(renderer));

但真正麻烦的是 VR 模式下的交互逻辑。桌面端的鼠标点击和键盘输入，在 VR 环境下完全失效，必须使用手柄射线。我使用的是 three.js 的 XRControllerModelFactory 和 XRHandModelFactory，通过 controller 对象的 addEventListener('selectstart') 事件监听手柄扳机键，同时用射线检测 Raycaster 判断手柄指向了哪个展品。

这里有一个容易踩的坑：如果只是单一相机加控制器，VR 渲染会出现严重的画面撕裂或者无法定位的问题。这是因为 three.js 在 VR 模式下需要将相机绑定到 XR 摄像机上，正确的初始化流程是：

renderer.xr.enabled = true; renderer.setAnimationLoop(function () { renderer.render(scene, camera); });

注意这里必须使用 renderer.setAnimationLoop，而不是传统的 requestAnimationFrame。只有 setAnimationLoop 才能与 WebXR 的渲染帧同步，确保左右眼画面正确合成。

为了适配没有 VR 设备的用户，我还加了一个降级逻辑：通过 WebXR API 检测当前设备是否支持沉浸式 VR，如果不支持，则自动切换为桌面端模式并用提示文字引导用户使用鼠标或手机陀螺仪浏览。这样既不会让普通用户迷茫，也不会影响 VR 体验的完整性。

3. zip在项目中的两种正确用法

3.1 工程分发：解压即用的目录结构

很多人下载到 zip 工程包后，第一步就是找 package.json 然后 npm install，但其实这个项目根本不需要。为了让“解压即用”落地，我把所有依赖库都放进了本地目录，而非通过 CDN 引入。最终的目录结构长这样：

three.js-VR展厅/ ├── index.html ├── assets/ │ ├── models/ │ │ ├── car.glb │ │ ├── sculpture.glb │ │ └── ... │ ├── textures/ │ │ ├── floor.jpg │ │ ├── wall.jpg │ │ └── ... │ └── packages/ │ └── scene-resources.zip ├── js/ │ ├── three.min.js │ ├── OrbitControls.js │ ├── GLTFLoader.js │ ├── DRACOLoader.js │ ├── RoomEnvironment.js │ ├── VRButton.js │ └── jszip.min.js └── README.txt

依赖库本地化的好处有两个：一是完全离线可用，局域网或者无网环境下解压也能跑；二是版本可控，不会被 CDN 的版本更新导致接口不兼容。缺点就是 html 文件里 script 标签会比较多，但换来的稳定性我觉得非常值。

index.html 是整个项目的入口，文件头部引用了所有需要的脚本，然后在 window.onload 事件里初始化场景。需要提醒的是，如果直接双击 index.html 打开，某些浏览器会限制纹理加载，建议至少起一个本地静态服务来访问。最简单的做法是在项目根目录执行npx serve，或者在 VS Code 里用 Live Server 插件启动。

3.2 运行时加载：用JSZip把资源包解到内存

除了把整个工程打包成 zip 用于分发，我还在项目内部用了一种运行时的 zip 资源加载方案。assets/packages 目录下有一个 scene-resources.zip，里面打包了展厅内所有展品模型和贴图。页面启动时，先通过 fetch 获取这个 zip 文件的 Blob，然后使用 JSZip 在浏览器内存中解压，拿到模型文件数据后再转成 Blob URL 交给 GLTFLoader 加载。

为什么要这样做？主要原因是为了减少 HTTP 请求数。如果直接在页面中加载十几个 GLB 模型加十几张贴图，浏览器的并发连接数会不够用，整体加载反而变慢。把所有静态资源压缩成一个 zip 包，只需要一次请求，解压过程完全在本地完成，加载效率会明显提升。

核心代码大致是这个思路：

const response = await fetch('assets/packages/scene-resources.zip'); const blob = await response.blob(); const zip = await JSZip.loadAsync(blob); const gltfEntry = zip.file('models/car.glb'); const arrayBuffer = await gltfEntry.async('arrayBuffer'); const url = URL.createObjectURL(new Blob([arrayBuffer])); const loader = new GLTFLoader(); const gltf = await loader.loadAsync(url); scene.add(gltf.scene); URL.revokeObjectURL(url);

这个方案的边界条件我也要说清楚：zip 包里的资源总大小最好控制在 20MB 以内，否则解压过程会导致页面卡顿。如果模型和贴图总资源超过 50MB，还是应该走 Draco 压缩加 CDN 分发的路线，不要在浏览器内存里做大文件解压。

3.3 Gzip与zip别搞混

这个项目里同时出现了两种压缩概念，很容易让人搞混：一个是 zip 压缩包，用于工程分发和资源打包；另一个是 HTTP 传输层的 Gzip 压缩，用于减少网络传输体积。很多朋友在本地起服务后发现页面加载还是很慢，以为把资源压成 zip 就能加速，其实服务器端还需要开启 Gzip 或 Brotli 压缩，尤其是对 GLB 这类二进制文件，开启 Gzip 后体积能减少 30% 到 40%。

如果你用的是 Nginx 托管这个项目，可以在配置文件里加上：

gzip on; gzip_types application/json application/octet-stream model/gltf-binary image/jpeg image/webp;

zip 解决的是“打包和分发”问题，Gzip 解决的是“传输速度”问题，两者是配合关系，不是替代关系。做 Web 端项目时，这两个概念一定要分开理解。

4. 实操中踩过的坑与排查实录

4.1 invalid zip archive: could not find EOCD

这个报错是在朋友反馈“解压失败了”的时候出现的，它是一个很典型的 zip 文件损坏错误。EOCD（End of Central Directory Record）是 zip 文件格式中位于文件末尾的一条目录记录，包含压缩包的文件列表和偏移信息。如果 zip 文件在下载过程中被截断，或者从某些网盘下载时被单线程下载器错误处理，EOCD 就会缺失，解压工具自然无法读取文件列表。

还有一种常见情况是：某个文件本身不是 zip 格式，只是扩展名改成了 .zip，这种文件也会报同样的问题。排查方式很简单，先用命令行工具验证：

unzip -t three.js-VR展厅.zip

如果输出显示 “End-of-central-directory signature not found”，基本可以确定文件损坏或者格式不对。解决办法是让文件发送者重新用标准压缩工具（7-Zip、WinRAR、macOS 自带压缩）压一次，不要随便改扩展名。

另外提醒一句，分享项目给别人时，不要在 zip 包上做程序化的读取逻辑，否则别人解压时容易因为压缩算法或编码问题报错。直接用标准 zip 格式最稳妥。

4.2 VR模式进去就黑屏或白屏

VR 模式下黑屏或者白屏，是项目调试阶段最折磨人的问题。造成黑屏的原因，首先是浏览器安全策略限制。WebXR 要求在安全上下文（HTTPS 或 localhost）中才能启动，如果你是通过 IP 地址访问局域网服务，并且没有配置 HTTPS，VR 按钮会直接不可用或点击后无响应。解决办法是在本地使用 localhost 调试，正式部署时做好 HTTPS 证书配置。

白屏的原因则通常是资源跨域问题。当 index.html 通过 file:// 协议直接打开时，浏览器会严格限制跨域请求，模型和贴图无法加载，渲染器即使初始化成功，场景也是空的。这种情况下在控制台能看到 CORS 相关的报错。解决方式是起一个静态服务器，而不是直接双击 index.html。

还有一个低级错误是忘记设置renderer.xr.enabled = true。如果这个属性没有打开，点击 VR 按钮也不会进入沉浸模式，只会触发系统校验错误。在接入 VR 的初始阶段，建议先跑通官网的 VRButton 示例，再集成到自己的场景里，这样排查问题更容易定位。

4.3 粒子效果不显示或者显示为黑块

粒子系统不显示，90% 的情况是材质或混合模式配置问题。使用 PointsMaterial 时，如果设置了vertexColors: true，必须在几何体上存在颜色属性，且颜色值要提供四通道（RGBA），否则粒子会显示为默认的黑色。黑色粒子在黑背景上自然就“隐身”了。

如果粒子显示为黑色块而不是发光点，则可能是混合模式的问题。我推荐的配置是：

material.blending = THREE.AdditiveBlending; material.depthWrite = false; material.transparent = true;

这几行配置的目的很直观：关闭深度写入让粒子之间不互相遮挡，使用叠加混合让重叠区域变亮而不是变暗，透明开启后粒子边缘过渡更自然。如果你的粒子效果看起来“脏脏的”，可以先从这里排查。

性能上也要注意，粒子数量不要盲目加大。我测试过 20000 粒子的场景，桌面端还有 40 帧，但手机端直接掉到 15 帧以下，体感非常卡顿。粒子系统是典型的高 CPU 和 GPU 消耗项，要配合用户设备的实际性能调整数量，或者做动态 LOD。

4.4 分卷压缩文件怎么处理

有次分享项目给朋友，他下载后收到了一堆.z01、.z02和最后一个.zip文件，然后很困惑地问“这个 .z01 文件没有对应的 zip 怎么办”。这里解释一下：分卷压缩是把一个大压缩包拆分成多个小文件，常见于网盘中单文件大小限制的场景。处理方式是用 7-Zip 打开扩展名为.zip.001或包含完整目录信息的主包文件，它会自动识别同目录下的其他分卷文件，合并解压。

千万不要手动把.z01改成.zip或者单独去解压某个分卷，这样大概率会得到损坏的压缩包。如果解压工具提示缺少分卷，检查一下所有文件是否在同一个目录下，以及文件名是否被网盘自动重命名。

顺带提一个项目分发时的小经验：如果压缩包超过 100MB，我一般会在 README 里写明“如果收到分卷文件，请把所有文件放到同一目录，用 7-Zip 打开第一个文件解压”。不然每次分发完，都要在聊天软件里回答一堆重复问题。

5. 最后分享几条我认为有用的经验

项目做完之后，有几个体会特别深。第一，three.js 项目不要一上来就套工程化框架，先用原生 script 标签把核心功能跑通，再考虑是否引入构建工具。很多项目其实根本不需要打包器，纯静态目录反而是最可靠、最容易分发的形态。

第二，资源优化永远是 Web 端 VR 项目的重中之重。模型压缩、贴图格式转换、纹理尺寸裁剪，这些工作在项目初期就应该规划好，不要等项目已经能跑起来了再回头优化，那时候改动成本会成倍增加。渲染性能和包体大小控制是这种项目能否被用户接受的生命线。

第三，多设备适配一定要提前测。60 帧的桌面体验很可能在手机上变成 20 帧。建议在开发阶段就同时开好几个终端窗口，用浏览器的设备模拟器看效果，有条件的话直接拿手机浏览器访问测试。像粒子数量、贴图分辨率、阴影质量这些参数，做成可配置项，方便根据不同设备动态调整。

最后再分享一个我自己的习惯：每次对外发压缩包之前，我都会在干净的环境里解压一遍，然后从 index.html 开始完整走一遍流程，确认没有绝对路径、没有缺失资源、没有报错日志，再发出去。这一个小小的检查动作，帮我避开了很多“打包成 zip 后跑不起来”的尴尬情况。如果你也打算用 three.js 做一个 VR 展示类项目，希望这篇文章能帮你少走一些弯路。

本文还有配套的精品资源，点击获取