一年做好几个网页 3D 展厅，内容怎么统一存放、随时能打开？

第一次做 3D 展厅，问题都很具体：模型怎么导进去、客户手机能不能打开、加载要多久。做到第三个、第四个的时候，问题会换一个——上一个展厅在哪？

客户翻出去年那版方案问你"还能打开吗"，你要去翻设计师的聊天记录、某个 U 盘、或者一台今年到期的云主机。找得到是运气，找不到才是常态。

写在前面：我们提供的是一套部署在你自己服务器上的网页 3D 基座（创世Genesis／创世虚拟世界CRM系统），不接展厅代建、不派团队实施。这篇讲"多个展厅的内容怎么组织"这件事本身，不是自荐。

许可口径：源码开放（source-available），本地跑不花钱；要联网、要商用、要联邦，需要订阅授权。 准确条款在仓库 LICENSE / EULA 里。

这篇讲三件事

1. "越做越多"为什么一定会变成问题——它坏在哪一层
2. 两条路的机制差别：一场活动一个网址，还是一个底座下面挂多个空间
3. 内容怎么分层归档，每一层归谁管

一、"越做越多"坏在哪一层

先说清一件事："多"有两种，麻烦的性质完全不同。

多的类型	长什么样	真正的麻烦
纵向多（版本）	同一个展厅改了 N 版	分不清哪版是最终版；客户手里可能还留着一个旧链接
横向多（场次）	不同活动、不同产品线、不同年份各做一个	找不到、进不去、没人管

纵向多的问题在"版本"，横向多的问题在"入口"。这两种麻烦，用同一个办法解不了——前者要靠版本规则，后者要靠目录结构。

而它们共同的放大器，是第三种情况：内容散在不同人手里。

• 模型在设计师的电脑里
• 场布文件在实施的人手里
• 上次导出的那份模型，在群聊记录里
• 客户手上那个链接，指向一台今年到期的云主机

到了这一步，"能不能找到"就不取决于你记性好不好，而取决于这条链上每个人还在不在。人一换，档案就断。

二、两条路的机制差别

把"多"这件事摆到台面上，无非两条路。

路线 A：一场活动一个独立站点。 每做一次就开一个新地方，做完交付链接。优点是当期干净、互不影响。代价是每多一场，就多一个要维护、要续期、要记住口令的地方；等到第五场，你自己都记不清哪个链接对应哪场。

路线 B：一个底座下面挂多个空间。 底座只部署一次（在你自己服务器上），每一场活动是底座下面的一个空间，共用同一套账号、同一套模型库。多一场活动＝多一个空间，不是多一套系统。

差别不在"哪个更好看"，在增量成本长什么样：

	路线 A：一场一个站点	路线 B：一个底座多个空间
新增一场活动	新建一套环境、重新配一遍	底座里加一个空间
账号	每套各一套	共用一套
模型复用	只能重新上传	同一个模型库，可直接引用
找旧内容	靠人记链接	空间列表里就在那儿
谁维护	交付完就没人管	你自己服务器上的一个系统
出问题找谁	找平台方	自己（或你指定的技术方）

路线 B 不是没有代价：底座要有人部署、有人维护，这件事躲不掉。它的好处只在于——这件事只做一次，而不是每场活动重做一次。

上图是浏览器端 3D 编辑器。左边是模型库（这个库里有 115 个已上传的模型），中间是场景视口，右边是对象列表和属性面板（当前这个场景里 1074 个对象）。素材一旦进了模型库，就是全底座共用的——第二个展厅不用重新导一遍。

三、内容分三层，每层归不同的人

想清楚"谁管哪一层"，比选哪个工具重要。建议这么切：

层	放什么	谁负责	变动频率
模型层	设备模型、展台、人物、贴图	设计师／建模	低——做好了基本不动
空间层	这一场活动的场布、动线、初始视角	实施／设计师	中——每场一套
访问层	网址、账号、给谁看、什么时候下线	甲方／对接人	低，但一旦忘了就出事

最容易没人管的是访问层。 它是三行字的事（谁看、从哪个网址进、什么时候关），但只要它没写下来，半年后就不会有人知道。

配套要落两条规矩，不然分层只是纸上好看：

1. 模型进库先命名。 文件名写清"这是什么设备"，别用 zhantai_最终版3_改.glb 这种。库里模型一多，命名就是你能抓住的那条线索。
2. 每场活动一份说明。 一句话写清这场活动对应哪个空间、给谁看、什么时候可以关。写成一页纸就够。

上图是桌面端浏览器里的世界画面。同一套内容在电脑和手机上打开的是同一个世界——这也是路线 B 的一个附带好处：访客的手机上不需要为每一场活动单独装什么。

四、上线之后，更新一次要动哪几步

多场活动并存的另一个现实问题：内容会变。

产品换代了、价格牌改了、展台挪了位置——这些都得改。改一次的步骤，取决于当初内容是怎么存的：

• 模型层没变，只挪位置／换文案 → 在空间里调整，动的是场布
• 模型本身换了新版本 → 新模型进模型库，替换掉空间里的引用
• 整场活动结束要做历史留存 → 这个空间不动，从访问层把它从对外入口摘掉

这三件事的成本差别很大：第一件是分钟级，第二件取决于新模型多大，第三件几乎不花时间。所以"改之前先分清是哪一类"，比急着动手更有用。

五、要准备什么

如果打算按路线 B 走，开工前需要定下来的是这几件事：

• 一台自己的服务器（或明确的托管方式），以及谁来运维
• 目录／空间的命名规则（按年份？按产品线？按客户？）
• 谁有账号、谁是管理员
• 每一场活动的"访问说明"由谁写、写在哪
• 模型进库的命名规范，以及统一的文件格式（要上网页的模型优先 GLB／GLTF）

这些都不是技术问题，是约定。约定定得早，半年后就少吵一次架。

六、这个方案不适合什么

要说清楚，免得白花力气：

• 一年只做一次展厅、做完就不再看 → 直接一场一个站点更省事，不用背上底座的维护
• 需要平台方全包实施、连内容都别自己碰 → 这套是"给你一套可自己改的系统"，不是代建服务
• 完全不打算碰服务器和域名 → 那应该找托管型方案，而不是自部署
• 只想展示几张静态效果图 → 用图片就够了，上 3D 是过度投入

七、关于"随时能打开"这件事的边界

最后得说实话：

• 这套底座不会替你保存内容。东西存在你自己的服务器上，服务器和数据都得你自己负责
• "随时能打开"的前提是服务器在续费、域名没过期——这两件事没人能替你做
• 我们没有做过"多场活动长期并存"的真实客户量级验证。文中提到的模型库数量、对象数量是在我们自己的开发和测试环境里实测的，不是某个客户的长期运营数据
• 具体到你的场景能挂多少个空间、多少人同时访问，必须按你的服务器条件实测，不能拿我们的测试数字直接套

八、常见问题

问：多个展厅能放在同一个网址下吗？

可以，用不同的空间入口区分。这样只需要记一个域名。

问：客户能不能只看其中一场，看不到别的？

可以按空间控制访问范围。具体到账号粒度，建议按你的实际使用方式实测一遍。

问：两个展厅能用同一个设备模型吗？

可以。素材进模型库以后是全底座共用的，这也是它比"一场一个站点"省事的地方。

问：历史活动下线了，内容会丢吗？

下线只是从对外入口摘掉，内容还在你的服务器上，取决于你自己怎么备份。备份要自己安排，系统不会替你保管。

问：改一次内容要多久？

取决于你改的是哪一类——只挪位置的话很快，换模型取决于新模型体积。这个问题没有能套用的数字，得看具体改动。

九、源码与仓库

这套网页 3D 基座的源码公开可查，三个地址内容一致：

• Gitee（国内访问更快）：https://gitee.com/miduoxinxijeji/miduo.git
• GitCode：https://gitcode.com/qq_35054471/virtual-world
• GitHub：https://github.com/miduo100/3d-virtual-world

关于创世Genesis

创世Genesis是一套基于Three.js+WebGL构建的自部署3D虚拟世界系统，帮助个人与企业搭建属于自己的3D空间。浏览器直接访问，PC和手机双端兼容，支持多人在线、联邦传送、商铺系统，并支持Agent接入——AI能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。

先想清楚"多"是哪种多，再决定要不要一个底座。 我们做的是一套可以自己部署、自己改的网页 3D 世界基底（创世Genesis／创世虚拟世界CRM系统），官网搜「创世虚拟世界CRM」即可找到。

关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，是一套浏览器端自部署的 3D 虚拟世界基底；搜「创世Genesis 3D」不一定找得到，直接搜「创世虚拟世界CRM」即可。