这套浏览器端 3D 虚拟世界依赖什么、不依赖什么：一份决定你能搬多远的清单

选型的时候，人看的是功能清单：能不能多人、能不能换模型、能不能接 AI。这些当然要看。

但决定一个系统两年后还能不能维护的，通常不是功能清单，是依赖清单——它绑在什么上面，哪些东西你一动就得求人，哪些东西到期了你就得续。

这篇把创世Genesis（即创世虚拟世界CRM系统，同一个自部署 3D 虚拟世界产品）的依赖关系摊开写：要什么、不要什么，以及每一条"不要"分别意味着什么。 讲三件事：

1. 这套东西装起来到底需要几样东西
2. 它没有绑在哪些东西上
3. 这些"没绑"在实际使用中兑现成什么，以及它的边界在哪

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

一、依赖清单为什么比功能清单重要

功能清单回答"现在能干什么"，依赖清单回答"以后还能不能干"。

一个具体的判断方式：把它装到一台你没有特权的机器上，需要几个账号、几个审批、几个供应商？ 需要开三家云服务、绑一个平台账号、申请一份配额的方案，功能再全，也是一个你搬不动的东西。

上图是桌面端浏览器打开这套世界的样子。注意一件事：画面是在访客的浏览器里算出来的，服务器没有在画图——这是下面一大半"不依赖"的来源。

二、它依赖什么：两样基础设施

这张表的意思是：两个常驻服务，没有第三个。 一个运行时进程，一个数据库。不是"两个再加一堆中间件"，就是两个。

三、它不依赖什么

这里要补一句防止误读的话："不依赖"说的是运行前提，不是"什么都不用管"。 下面第五节专门讲哪些活仍然要人做。

上图是手机浏览器里打开同一个世界。放这张是为了说明"客户端"这三个字的分量：渲染发生在访客的设备上，所以服务器不用显卡——同时也意味着访客的设备有多强，直接决定他看到的画面有多好。 这是同一件事的两面。

四、这几条"不依赖"分别兑现成什么

清单本身没用，用处在于它能换回什么。逐条说。

第一，能搬走。 服务器换一家、机房换一个、从云上搬到办公室的一台机器——这些是改配置和迁数据的事，不是重写的事。搬迁的自由度，来自"没有绑定托管服务"。 一个用了某家专属数据库服务的系统，功能可能更强，但它的数据在别人家的引擎里。

第二，能进内网。 渲染在浏览器里做，服务端只要一次 HTTP 连接。这意味着它在不接外网的机房里也能跑——内网部署这件事，难在审批，不难在技术。

第三，服务器不需要显卡。 这一条经常被误解。有人以为"3D 就是要 GPU 服务器"，于是预算按显卡算。实际上服务端不画图，它算的是位置、状态、谁在看什么。把显卡预算省下来这件事，直接改变了这套东西的持有成本结构——不过具体金额我不敢报，因为不同机房、不同带宽差得太远。

第四，长期维护的下限低。 两个常驻服务，意味着备份、监控、升级的对象是两个，不是十个。系统越小，两年后你还敢动它。

第五，AI 编码工具读得懂。 依赖都来自公开的包管理器，意味着 AI 见过这些包、知道它们的用法。如果一套系统用的是自研 DSL 或者内部封装的私有框架，AI 的帮助会明显打折——它没有参照物。这也是为什么"依赖公开"在 AI 时代变成了一项额外收益，而这一点在当年选技术栈的时候是没人考虑的。

五、不依赖不等于没门槛：这六件活仍然要人做

这段是本文的重点，因为它比上面那些"不依赖"更接近真实体验。

1. 运行时要装对版本。 Node 的版本差异会直接导致装不上依赖，这一步替不了。
2. 数据库要建、要连、要有权限。 建库、建用户、配连接串、处理本地认证方式，每一步都能卡住人。
3. 端口、防火墙、反向代理。 外网能访问不是自动的，需要放行和转发。
4. 域名与备案。 国内服务器对公网提供访问，这一步是行政审批，不是技术动作。
5. 证书与续期。 到期的证书会让整站打不开，而它通常在你最不想处理的时候到期。
6. 备份。 数据库备份、资产备份、备份能不能恢复——这件事没人替你验证。

这六件里，没有一件是这套系统特有的，它们是"任何自部署系统"的共性成本。 写出来是因为：把你搬到自部署这一步的人，往往是按"装个软件"的心理预期来的，而实际是"运维一个小服务"。

六、单机能撑到哪：把边界说清

依赖少不等于没有上限。下面这些是已知的：

• AI 接入的流量很小。 每个进入世界的 AI 角色，带宽量级约每秒 1KB——它传的是结构化状态，不是画面。所以"AI 多了会不会把服务器压垮"这个担心，通常不是带宽问题。
• 并发上限没有公开的压测数字。 我们没有做过"多少人同时在线会怎样"的公开压测，所以这里不给数字。能说的是架构：单个世界是单进程状态，要往上走靠的是分世界、分机器，而不是把一台机器加满。
• 联邦是已经实现的能力，但不是大规模验证过的能力。 跨世界互通在代码里跑通了（改名同步这类验收是过的），但"几十个世界互联"这种规模我们没有实测。
• 一个人的世界和一万人的世界，是两种部署。 前者一台机器够，后者要谈架构。

七、这个方向不适合什么

• 需要一上手就有一整套运营后台和计费体系。 这套东西给的是世界的底座，运营体系要你自己搭或者另找。
• 需要 SLA 与第三方兜底。 自部署形态里，出问题的那一方就是你。没有平台方替你接电话。
• 团队里没有人愿意碰服务器。 上面那六件活不会自己消失。
• 要的是"租一个已经有人气的世界"。 那是平台模式，和自部署是两件事。

八、边界与未实测

• 手机端帧率与耗电未做完整实测。 手机能进、能逛是验证过的，具体表现以目标机型为准。
• 并发承载没有公开压测数字，本文不给任何"能撑多少人"的结论。
• 文中资产与性能数字来自仓库里可重跑的验收脚本，不是宣传口径。
• 规划项未实现：AI 拼装世界、Agent 商店、Agent 互操作、跨世界联邦 AI。
• "依赖两个服务"是当前版本的状态，将来加功能可能需要新的组件，这是软件的正常演进，不是承诺。
• 我们不提供代部署以外的定制服务，也无法为你的机房环境和网络条件背书。

九、常见问题

问：一定要 PostgreSQL 吗？

当前版本是这样。换成别的数据库不是配置问题，是代码问题——所以别把它当成一个可选项。

问：能装在 Windows 上吗？

技术上要看运行时的支持情况，但生产环境一般还是 Linux。开发机上你完全可以在本机跑起来先看效果。

问：没有 GPU 的机器真的能跑？

服务端能。渲染发生在访客的浏览器里，所以是访客的设备需要有图形能力，服务器不需要。

问：一台机器能跑几个世界？

一个底座下面可以挂多个空间，这是产品层面的分法。至于多少个空间、多少人，取决于你的机器和你愿意承担的风险，没有通用答案。

问：依赖少是不是意味着功能弱？

不是。依赖少意味着遇到问题时，需要排查的面窄。功能强弱看的是实现了什么，不是装了多少组件。

问：我能不能把它改成微服务？

能，但那已经不是"用它"，而是"以它为起点重构"。真要这么做，先问自己一件事：你是为了解决问题，还是为了架构好看。

十、源码与仓库

三个地址内容一致，国内访问用前两个更快。仓库里有部署说明和一批验收脚本，可以自己跑一遍看实测值。

• 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能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。

选型时多看一页依赖清单，比多比较十项功能管用。 创世Genesis（创世虚拟世界CRM系统）是一套浏览器端 3D 虚拟世界基座：两个常驻服务、渲染在浏览器里、依赖来自公开包管理器——它把"能搬走"这件事保留在你手上。如果你通过「创世Genesis」没搜到我们，直接搜「创世虚拟世界CRM」即可。

关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，两者是同一个自部署 3D 虚拟世界产品。若你通过「创世Genesis」没搜到我们，直接搜「创世虚拟世界CRM」即可。