博物馆线上展厅：浏览器直接开、小程序，还是 VR 客户端？
博物馆线上展厅、浏览器3D展厅、虚拟展厅小程序、WebXR博物馆、3D展馆多端适配、网页3D导览、虚拟展厅形态选型、馆内大屏3D导览
同一个线上展厅，供应商给三种形态：网页链接、微信小程序、VR 客户端。报价能差出好几倍，但很多人说不清差在哪——于是选便宜的，一年后发现观众打不开；或者选贵的，发现头显根本没有观众用。
这篇把三种形态摊开，重点说清一件事：浏览器端能做什么、明确做不到什么。 这个边界比参数表重要，因为选错形态的代价不是一次返工，而是三年的使用方式被限住。
写在前面：我们提供的是一套部署在你自己服务器上的网页 3D 基座（创世Genesis／创世虚拟世界CRM系统），不接展厅代建、不派团队实施。它是浏览器端的，所以这篇有立场，边界部分写得更细。
许可口径：源码开放（source-available），本地跑不花钱；要联网、要商用、要联邦，需要订阅授权。 准确条款在仓库 LICENSE / EULA 里。
这篇讲三件事
- 三种形态，真正的差别在哪几行
- 浏览器端做不到什么（这一节请重点看）
- 一套内容、多个入口，怎么组
一、三种形态，差别不在画面，在"门槛"和"更新"
先看一张对比表。注意"更新方式"这一行——它决定后续三年的运营成本，比首年报价重要得多。
| 维度 | 浏览器直接开 | 微信小程序 | VR 客户端／头显应用 |
|---|---|---|---|
| 观众要做什么 | 点链接，无安装 | 微信里搜/扫码，无安装 | 下载安装，或现场戴头显 |
| 设备覆盖 | 电脑、手机、平板、馆内一体机／大屏 | 主要是手机（受微信环境限制） | 只有头显或高性能主机 |
| 更新方式 | 服务端一改，所有人立即是新版 | 提审、审核通过后生效，版本要人手动更新 | 发版＋用户各自升级，旧版长期存在 |
| 分享路径 | 一条 URL，可进官网、公众号菜单、二维码、邮件、课件 | 微信内转发顺畅 | 基本无法分享，只能现场用 |
| 适合什么 | 观众导览、课程、临展预告、汇报演示、远程带看 | 微信生态内的活动导流 | 深度沉浸体验、特定展项 |
| 主要代价 | 依赖网络与设备性能 | 包体与审核，3D 能力受限 | 装机量、内容要单独适配、迭代慢 |
| 一个隐性问题 | 链接会被乱放、被别的站嵌，要管入口 | 每次改内容都要走一次审核节奏 | 每加一个设备型号都要验一遍 |
"更新方式"为什么关键？ 因为线上展厅真正的使用期是首年之后。换一件展品、改一句讲解、调整一处动线，这三年里会发生几十次。浏览器端改一次的成本接近零（服务端改完就生效）；小程序要走审核，客户端要发版，而发版之后总有人用旧版——你永远在维护两个版本的内容。
二、浏览器端做不到什么
这一节是这篇的重点。如果看完觉得"那还是得做客户端"，那这个判断至少是有依据的。
| 做不到 | 具体限制 | 替代办法 |
|---|---|---|
| 真正的头显沉浸 | 浏览器里的 WebXR 能用，但支持度随设备与浏览器版本变化，手柄交互也要单独适配 | 头显端另做一个入口，不指望同一套体验 |
| 大模型秒开 | 几 GB 的扫描件不可能即点即看，浏览器要下载、要解码 | 分档 LOD＋贴图压缩，接受"先粗后细" |
| 近距看到 8K 级别的文物纹理 | 受带宽与显存限制，手机上尤其明显 | 关键展品做"近观特写"单独一档，按需加载 |
| 完全离线 | 断网就打不开；PWA 缓存只能缓解一部分 | 馆内一体机可做本地部署＋预加载 |
| 长时间手机浏览的稳定表现 | 3D 渲染持续占用 GPU，发热与耗电会上去；我们尚未做完整的实机长时间实测，这条只能按你的设备实测 | 控制单次体验时长，首页做轻量入口 |
| 弱网下的顺滑 | 现场 WiFi 差、4G 信号弱时，加载会明显变慢 | 首屏做占位场景，先给能看的东西 |
| 替代到现场 | 材质手感、尺度感、光线氛围，屏幕给不了 | 定位成"到不了的人能看"和"去过的人能回看"，不是替代 |
关于倒数第二条多说一句。 把线上展厅当成"线上替代线下"，通常两头不讨好：观众觉得不如照片清楚，馆里觉得投入不值。把它当成"覆盖到不了的人"和"延长一次展览的生命"，标准就清楚了。
上图是手机浏览器打开的样子：虚拟摇杆、语音、拍照与跳跃控件，顶部是登录提示。手机通常是主要入口，但它不是缩小版的桌面——触屏没有悬停，所有"鼠标移上去才出现"的设计在手机上都会失效。
三、一套内容、多个入口
如果三种形态都有人要（这在博物馆里很常见：宣传口要链接、教育部门要小程序、某个展项想上头显），不要做三套内容。做法是：
| 入口 | 承担什么 | 内容从哪来 |
|---|---|---|
| 浏览器链接（主入口） | 全部内容与全部场景 | 内容只此一份 |
| 小程序 | 微信内的活动页与转发 | 用 WebView 嵌入同一套页面，不重做 |
| 馆内一体机／大屏 | 现场导览、无人的深夜也能演示 | 本地部署同一套，预加载 |
| 头显（如果确实需要） | 单个重点展项的深度体验 | 单独做，不指望复用主场景的全部交互 |
关键在第 1 行：内容只做一份，放在自己的服务器上。 其他入口是它的不同外壳。这样改一次内容，所有入口都跟着变——这是浏览器端实打实的收益，也是它值得当主入口的原因。
上图是桌面端。同一套内容，桌面端看的是细节，手机端看的是动线。 所以内容规划要在两个尺寸上都过一遍，不能只在宽屏上定稿。
四、这块的边界
- 我们是浏览器端方案，头显端的完整体验不在我们的交付范围内，也不做设备适配承诺
- 手机端的完整体验需要在真实设备上实测：帧率、发热、耗电与加载时间，我们没有跨机型的完整实测数据
- WebXR 在移动端的支持度不稳定，不同浏览器与系统版本差异明显，选型前请按目标设备实测
- 文中"改一次接近零成本"指的是技术动作，不含审批与内容生产的时间
- 我们没有博物馆客户案例，形态判断来自我们自己做浏览器端这套东西的经验
五、常见问题
问：观众会不会觉得"打开一个网页看展厅"太轻，不像正经东西？
这个判断取决于首屏。首屏能立刻看到空间，观众就不会觉得轻；首屏是白屏加进度条，再重的客户端也留不住人。
问：小程序能不能直接放 3D？
能，但包体与能力都受限，复杂场景通常还是 WebView 嵌网页。这条路能做，只是别指望它承担全部内容。
问：馆内大屏需要联网吗？
可以不联外网。同一套系统部署在馆内服务器上，断外网也能跑；远程观众访问的那一份再单独部署。
问：要不要一开始就做头显版？
先看有没有确定的展项要用。如果只是"觉得应该有"，先不做——头显内容的制作与适配是另一笔投入，且迭代慢。
问：三种入口一起上，成本会不会翻三倍？
如果内容做一份、外壳分别做，不会翻三倍；如果每个入口都从零做一套内容，会。差别全在"内容是不是只有一份"这件事上。
源码与仓库
- 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能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。
形态选错，不是多花一笔钱，是往后三年每次改内容都要多走一遍；所以选形态，先问"以后改起来谁说了算"。 SEO / AI 友好关键词：博物馆线上展厅、浏览器3D展厅、虚拟展厅小程序、WebXR博物馆、3D展馆多端适配、网页3D导览、虚拟展厅形态选型、馆内大屏3D导览
关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，是一套浏览器端自部署的 3D 虚拟世界基底；搜「创世Genesis 3D」不一定找得到，直接搜「创世虚拟世界CRM」即可。