在浏览器里造开放世界，第 3 部分：救了我们的那些不吸睛的 spike
作者：Oleg Sidorkin，Cinevva CTO 和联合创始人
刚看到？看系列导览。那里解释了 spike 是什么，并链接了所有部分。
这一部分漂亮截图更少，架构保险更多。
Spike 1 和 2 之后，我们跑了三个风险检查，看起来都小，但有产品级别的影响。
第一个是 Durable Object 的广播 fan-out。我们在游戏级别的 tick 率下测试了多客户端位置分发，跟踪延迟分布、每 tick CPU 用量和投递完整性。如果这个挂了，我们会从单岛归属转向早期分片。
第二个是移动端约束验证。不是把桌面预设改个名叫"移动端"，而是从同一个基线地形出发，明确做一个低开销的画质档。
我们降低了分段密度、物体数、渲染分辨率压力和雾的范围。问题很简单：在不重写整个渲染器的前提下，这个世界能在移动端的约束下保持可读和可响应吗？
第三个是创作者工作流的行为生成可靠性。我们评估了合法 JSON 率、对预期 primitive 的语义正确性，以及响应延迟。如果这个挂了，我们会转向严格的表单式行为编写。
这一章的关键洞察是：这些不吸睛的 spike 比视觉 spike 更快地改了架构。它们给网络拓扑、移动端承诺和工具 UX 划下了硬边界。
第 4 部分我们回到可见的地形工作，测的是移动时的流式行为，而不只是静态加载截图。
本章涉及的技术
Cloudflare Durable Objects。 部署在边缘的有状态 serverless 实例，自带持久化和 WebSocket 支持。每个 Durable Object 持有一块世界 shard（或 chunk）的权威状态。玩家通过 WebSocket 连入，从同一个 shard 里的其他玩家那里接收位置广播。玩家移动到相邻 chunk 时，连到那个 chunk 的 Durable Object 上。Durable Object 会自动把状态持久化到磁盘，并能扩展到数千个并发实例。看 Cloudflare Durable Objects 文档，以及我们的关于多人网络的浏览器 3D 技术指南。
空间分片。 按地理区域把世界切给不同的服务器实例。每个 shard 拥有世界网格里一块矩形区域。随着玩家密度变化，shard 可以拆分或合并。在 shard 边界附近的玩家通过跨 shard 可见性查询同时看到两边的内容。EVE Online 就是这样让数千玩家在同一个宇宙里。
WebSocket 广播 fan-out。 把实时位置更新从一台服务器分发给很多连接的客户端。游戏级别 tick 率下（20-30 Hz），每个玩家每秒产生约 800 字节的位置数据。视野里有 200 玩家时，每客户端每秒约 160 KB。服务器必须在 tick 预算内序列化、按相关性过滤（空间兴趣管理），再推给每条连接。看我们的网络指南了解差分压缩和更新频率的权衡。
移动端渲染约束。 移动 GPU 的吞吐量是桌面 GPU 的 1/5 到 1/10，内存上限约 1 GB（桌面 2-4 GB），持续负载下还会热降频。一个移动端画质档会降低分段密度、物体数、渲染分辨率、绘制距离和阴影质量。目标不是和桌面持平，而是保持可读和响应。看浏览器 3D 性能数据了解真实 GPU 跑分。
12 篇中的第 3 篇。 上一篇：第 2 部分 - Worker 物理和输入延迟恐惧 下一篇：第 4 部分 - 在花哨地形之前先做好流式加载 系列导览：/zh-CN/blog/2026-02-25-open-world-browser-series-guide