前段时间把 OmniGame 这个项目彻底推翻重写了一遍核心约束就两个运行时零依赖全套代码自己写联机走 WebRTC P2P 而不是服务器中转。做完之后我最大的感受是网页小游戏的工程上限长期被“框架 服务器”这两个默认前提压住了。而当你把“零依赖”和“P2P”放在一起分发方式、成本模型、联机方案甚至玩法设计都会被重新打开。这篇文章想把整个 OmniGame 从选型、握手、数据同步到踩坑排查的过程完整讲一遍。适合两类人一类是零基础但想用纯 HTML JavaScript 做联机小游戏的前端开发者另一类是本来玩过 WebSocket 服务端联机、但一直好奇 WebRTC 到底怎么落地的玩家。你不需要懂后端也不需要买服务器最多准备一台能联网的电脑和两个浏览器窗口。看完全文你会发现一个真正能和朋友联机的网页小游戏工程上可以轻到你难以想象。1. 为什么“零依赖”值得当作一条项目原则单看“零依赖”这个词很多人第一反应是“那不就是不用 React、不用构建工具吗”。实际上它影响的远不止开发体验而是从代码加载、可移植性再到长期维护一整条链路都被这个决定重新塑造。我先说清楚源头。1.1 一切的起点“复制链接就能玩”OmniGame 的出发点特别朴素就是从很多游戏交流群里那种经典需求开始的有人想要一个不用下载 App、复制链接到浏览器就能打开、拉上朋友就能一起玩的网页小游戏。如果是单机游戏这个目标一个 HTML 文件就能满足但如果要联机那就会遇到一个矛盾——常规联机方案要么需要一个服务器要么需要至少两方都能访问某个中间设施而这些恰恰是“零门槛分享”最想避免的。我在观察了很多纯 HTMML JS 的小游戏项目后有足够信心确认真正能把分享门槛压到最低的形态就是单文件。你不用管 npm install不用管 Vite 配置不用管用户有没有正确安装运行时。一个 index.html拖进浏览器就能跑放进任意静态托管就能分享。所以 OmniGame 的第一条原则就定了运行时零依赖整个游戏只由标准 HTML/CSS/JS 组成用户侧不需要安装任何东西。1.2 零依赖带来的三个隐性收益很多人以为零依赖是为了“显得硬核”其实它更像是一种工程上的退而求其次——当你把所有第三方代码都拿掉之后剩下的每个问题都必须自己解决这反而逼着项目结构变得异常清晰。具体收益我总结为三点第一个是加载性能。没有框架意味着首包就是实际代码的体积不需要先下载几百 KB 的运行时再跑业务逻辑。OmniGame 这种小体量的游戏完整逻辑压缩后大概 20KB 到 40KB 就能搞定对比动辄 200KB 起步的框架应用一个网页游戏在普通 4G 网络下几乎是秒开。第二个是可移植性。因为只依赖浏览器标准 API这个游戏可以本地 file:// 直接打开可以放到任何静态托管平台可以塞进企业内部工具里甚至可以刻在光盘里十年后再打开都能跑。这就像一份纯文本笔记无论操作系统怎么换、软件怎么升级永远不会“打不开”。第三个是可维护性。这一点我是在项目做到一半才真正体会到的零依赖项目没有依赖链就不会有连锁升级问题。不需要因为某个框架大版本升级而重构 API不需要担心某个中间库停止维护后留下一堆漏洞。三年后打开这个项目代码还能跑、还能改对个人项目和小型实验来说这太重要了。1.3 零依赖不等于不用工程手段这里必须澄清一个常见误解零依赖说的是运行时没有任何外部软件包依赖但工程上反而更需要纪律。OmniGame 在源码层还是严格区分了 network、game、render、util 这些模块的开发时按模块拆文件发布时合并成单文件。如果你用 ES Module 的 import/export在 http 环境下部署完全没问题但如果你期望的是“双击 index.html 就能离线打开”要注意浏览器的 CORS 限制会拦截本地模块加载。我踩过一次这个坑开发时一切正常一到离线打开就全部空白控制台报 CORS。后来用了最简单的方案——开发拆模块发布时用一个小脚本把所有文件拼成一个 IIFE既保留了模块化的可读性又保证了单文件在那个最极限的环境下能运行。我自己写了十行左右的 Node 合并脚本完全不算额外的框架依赖。2. 联机方案选型为什么非 WebRTC 不可网页游戏只要带上“联机”两个字先要解决的就不是玩法问题而是数据怎么从 A 到 B。传统方案是中心服务器中转WebRTC 给出的答案是浏览器之间直连。这个选择直接决定了整个项目的成本结构和线上体验。2.1 传统联机方案的隐形代价HTTP 轮询是最土的方案客户端每隔几百毫秒问一次“有没有新状态”连实时性都谈不上。WebSocket 比轮询好得多是全双工长连接但它依然需要一个始终在线的服务器这个服务器要接收所有玩家的连接、转发每一条消息、处理重连和异常还要掏带宽和运维成本。一个非常现实的对比一个只有 50 人同时在线的小游戏如果走 WebSocket 中转你至少需要一台 2 核 4G 的云服务器而且带宽是按峰值购买不是按实际用量。如果游戏在社交平台突然爆了服务器就得马上扩容否则就卡死如果没什么人玩服务器还得常年挂着白白烧钱。对于个人开发的网页小游戏这是一笔几乎永远收不回来的成本。OmniGame 最初的标准是“零后端”所以 WebSocket 方案一开始就被排除了。我需要的是不需要任何常驻服务器玩家双方之间直接建立连接数据从一方手里传到另一方手里的过程中没有任何中转节点。这就是 P2P。2.2 WebRTC 是浏览器自带的能力WebRTC 的全称是 Web Real-Time Communication很多人一听到它第一反应是“网页视频通话”实际上它是一个标准化的协议加浏览器 API 集合核心包含三块能力媒体流传输音视频、DataChannel任意二进制数据通道、NAT 穿透全球网络环境下帮助两端找到对方。OmniGame 用到的主要是 DataChannel 和 NAT 穿透。我平时给完全没接触过的人解释 WebRTC常用一个类比你在一个园区门口的访客中心登记身份得到一张临时通行牌然后你们俩直接去后面的会议室私下聊天之后所有对话都不需要再经过访客中心。这个“访客中心”就是信令服务器只需要在最开始阶段帮忙交换几 KB 的连接参数真正聊天时它完全不参与数据链路。这点太关键了甚至可以说它是整个 P2P 架构的灵魂信令服务器和游戏服务器是完全两回事。前者只在建连瞬间出现后者是每分每秒都要处理消息。选择了 WebRTC等于把“每秒钟都在线”的服务器开销压缩成“建连时闪一下”的极轻量服务。2.3 信令是个绕不开的微妙环节必须先交代清楚一个看起来矛盾的事实零依赖不等于零服务器。WebRTC 里有个叫“信令”的过程双方需要交换各自的 SDP会话描述协议和 ICE 候选信息否则没法建立连接。这个交换过程需要某一方帮忙“传话”这就是信令服务器。但信令服务器的意义被很多刚接触 P2P 的人误解了它只是传递几 KB 的构建参数之后所有游戏状态、位置坐标、操作指令全部走 WebRTC 的 DataChannel完全不经过它。所以它不是一个“游戏服务器”更像是两个陌生人初次见面时的介绍人——介绍完就可以走了。在 OmniGame 里信令方式我做了三种渐进式方案最原始的是手动复制——发起方生成一串 offer 文本复制给对方对方粘贴后返回 answer两边再粘贴 ICE 候选可选方案是用二维码把 offer 编码成二维码扫码即获得文本进阶方案是部署一个极小体积的 Serverless 信令函数只转瞬交接几段文本就结束。三种方案对零依赖原则都不冲突因为游戏运行时不需要任何中心组件。2.4 WebSocket 与 WebRTC 的真实差异用表格直接对比这样更直观对比维度WebSocket 中转WebRTC DataChannel数据路径客户端 A → 服务器 → 客户端 B每一跳都会增加延迟A 和 B 直连最快路径无中转服务器成本需要常驻服务器带宽按峰值计费只需要轻量信令服务或手动交换几乎零成本数据可靠性TCP 语义但消息经服务器转发可能排队可配置可靠或部分可靠模式NAT 穿透无穿透问题服务器兜底一切需要 STUN/TURN 协助部分网络必须 TURN 中继断线重连客户端重连服务器即可两端都需要重新协商逻辑更复杂浏览器兼容性全平台稳定现代浏览器基本支持但仍有边缘差异开发复杂度服务端逻辑繁琐但客户端简单客户端要做信令、ICE 收集、重连复杂度更高选择 WebRTC 的本质原因就是延迟和服务器的双重收益。尤其两个人的小游戏延迟高 100ms 就是天壤之别你按下跳跃你朋友那边要在 100ms 之后才看到你跳起来体感就是“这个游戏好卡”。P2P 直连在家庭宽带和移动网络下RTT 通常能压到 20ms 到 60ms 之间这个体感差异是质变的。有优势就有代价。WebRTC 的浏览器兼容性、断线重连、ICE 失败的排查难度都比 WebSocket 高一个数量级。所以我的结论从来不是“WebRTC 一定比 WebSocket 好”而是如果你做的是两个人到四五个人的实时小游戏服务器预算几乎为零那么 WebRTC 是更本质的方案。如果要做万人同服、排行榜、账号系统那还是老老实实走中心服务器P2P 不是万能药。3. 核心实现信令握手、DataChannel 与状态同步联机方案的骨架确定后剩下的问题就是具体的代码怎么写、参数怎么调、数据怎么高效传。这一章是 OmniGame 真正的工程核心我把从建连到同步的关键实现全部拆开讲。3.1 最小信令交换流程先说最基本的建连流程。我是主机还是客户机通过一个简单的房间号来区分主机创建房间客户机加入房间。主机创建 RTCPeerConnection然后生成 offer客户机收到 offer 后生成 answer两边交换 ICE candidate最终建立连接。下面是用 JavaScript 描述的最小实现思路核心是 RTCPeerConnection 和 onicecandidateconst pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.l.google.com:19302 } ] }); // 主机调用创建 DataChannel 并发送 offer function startHost() { const channel pc.createDataChannel(game, { ordered: false, maxRetransmits: 0 }); channel.onmessage (e) handleRemoteMessage(e.data); pc.onicecandidate (e) { if (e.candidate) sendSignal({ type: candidate, data: e.candidate }); }; const offer await pc.createOffer(); await pc.setLocalDescription(offer); sendSignal({ type: offer, data: pc.localDescription }); } // 客户机调用接收 offer、生成 answer async function joinAsGuest(offerSdp) { pc.ondatachannel (event) { const channel event.channel; channel.onmessage (e) handleRemoteMessage(e.data); }; pc.onicecandidate (e) { if (e.candidate) sendSignal({ type: candidate, data: e.candidate }); }; await pc.setRemoteDescription(offerSdp); const answer await pc.createAnswer(); await pc.setLocalDescription(answer); sendSignal({ type: answer, data: pc.localDescription }); }这段代码里最容易漏掉的一步是 trickle ICE 的处理。默认情况下ICE candidate 是异步生成的可能在 offer 被接收之后好几百毫秒才陆续到达所以两边都必须一直把候选转发给对方直到连接完全建立。千万别以为 offer 和 answer 交换完就万事大吉没走完 ICE 收集流程就急着发游戏状态连接会卡在半路。3.2 DataChannel 的可靠性参数是游戏手感的分水岭DataChannel 有两种核心传输模式可靠有序模式相当于 TCP丢包重传但一个包丢了之后后续包都得排队等着这会让游戏出现“老操作堵住新操作”的头部阻塞部分可靠模式ordered: false允许丢包或限制重传次数牺牲一点点可靠性换取实时性。OmniGame 里我的配置是const channel pc.createDataChannel(game, { ordered: false, maxRetransmits: 0 });这个配置意味着消息一旦发送如果丢包就不重传。对位置同步、特效播放、输入操作这些实时数据丢一个旧包远比重传后导致整条链路延迟飙升要舒服。打个比方赛跑游戏里你朋友看到你 50ms 前的位置体验依旧流畅但如果一个位置包丢了网络层傻傻地重传那 500ms 后他才看到你 500ms 前的位置这时候游戏世界就彻底乱了。可靠有序模式也有它的用武之地比如房间开始时的初始状态同步、双方战绩的最终结算需要保证不丢失、顺序不混乱。OmniGame 的做法是在 DataChannel 之上再做一个简单的消息类型区分UDP 类型的实时消息走部分可靠通道TCP 类型的初始化消息单独走可靠通道。实现方式就是创建两条 DataChannel一条硬实时一条高可靠互不干扰。3.3 从 JSON 切成二进制后消息体积直接砍到十分之一先给一组我自己测试过的数字用 JSON 序列化一个玩家操作大致是 {“id”:1,”seq”:123,”x”:320.5,”y”:240.2,”dir”:2}序列化后大约 80 到 120 字节。看起来不大但一个游戏一秒钟要传 10 到 20 条这样的消息两边加起来就是 4KB/s在移动网络下也算不了什么真正的问题是大批 JSON 解析和字符串拼接带来的 CPU 消耗。在小游戏这种本来资源就紧的场景里每一毫秒都很宝贵我后来把消息格式全部改成二进制每条消息固定 12 字节。二进制协议的设计非常直接用一个固定长度的字节数组表示一条输入消息function encodeInput(playerId, seq, x, y, dir) { const buf new ArrayBuffer(12); const view new DataView(buf); view.setUint8(0, playerId); // 1 字节玩家ID view.setUint16(1, seq); // 2 字节序列号 view.setFloat32(3, x); // 4 字节x坐标 view.setFloat32(7, y); // 4 字节y坐标 view.setUint8(11, dir); // 1 字节方向 return buf; }12 字节对比之前 JSON 的 80 到 120 字节体积直接缩到十分之一以内解析也不再需要 JSON.parse直接 DataView 取值。这个改动对玩家体感的提升很直接哪怕依然是 20ms 延迟但所有玩家在低端安卓机上都能稳定 60 帧渲染。如果你觉得 12 字节还是太多了可以继续压坐标用 16 位整数而不是 float32方向用 3 个 bit这样单条消息可以压到 8 字节甚至更少。但压缩的边界在于调试痛苦字节已经没法一眼看出来了所以 OmniGame 的开发模式里保留了 JSON 格式的开关只有生产环境切二进制。我的个人经验是别贪12 字节已经足够优雅且调试成本可控。3.4 状态同步到底选“输入同步”还是“帧同步”网页小游戏的联机同步方案大致有两个流派帧同步和输入同步。帧同步的思路是所有客户端在同一帧执行同一条输入严格对齐输入同步的思路是每个客户端模拟自己的世界本地输入立即生效远程玩家的输入通过网络及时到达后合并进世界状态。OmniGame 用的是输入同步加乐观更新本地玩家按下操作立即更新自己的坐标和动画远程玩家的操作到达后用“缓冲区 时间戳”做一个小延迟缓冲避免对方的位置和动作疯狂抖动。这个方法最大的优点是对丢包容忍度高——偶尔丢一两条输入世界只是错过一个小小的动作不会崩溃如果是帧同步一帧的输入丢了整局都得重开。帧同步适合音游和格斗游戏那种强韵律、强公平性的玩法但对普通玩家来说输入同步的联系感和宽容度更好开发起来也更容易调试。我强烈建议中小型网页小游戏优先从输入同步起步复杂度和玩法契合度都高得多。4. 从 Demo 到能真正玩起来四个工程问题实录代码跑通之后离“能和朋友一起玩”还有一段距离。这一段我按实战顺序记录了四个我全过程踩过、也最终解决的工程问题。4.1 没有服务器房间号怎么来传统联机房间需要一个中心服务器保存房间列表。P2P 游戏没有这个服务器房间号其实只是一种“建连参数”的封装发起方随机生成一个六位房间码同时生成 offer。对方拿到房间码后再通过手动复制或信令服务获取 offer建立连接。更极简的办法是?roomabc123参数自动填充房间码——这样你分享链接时把房号直接写进去朋友打开链接时就能自动带着房间号完成连接全程不需要输入任何东西。OmniGame 的可选搬法是这样分享出来的链接长这样https://example.com/omni/?roomK7F2Q9打开之后页面直接进入等待连入模式guest 打开同一个链接后自动发起连接。因为整个游戏就一个 HTML 文件把room参数解析出来再走信令流程完全不需要服务器。实战里这个方案让连入成本降到了极低我已经习惯了发给朋友后直接说“打开这个链接等两秒就进”。4.2 ICE 与 NAT为什么有些用户死活连不上这里得说说 NAT 穿透的基本原理。家用路由器一般会做一个公网 IP 和端口到内网 IP 和端口的映射两个不同家庭网络里的玩家借助 STUN 服务器拿到自己在外网看到的 IP 和端口之后通常可以绕过路由器直接建立 P2P 连接。但对称 NAT 和企业防火墙就很麻烦必须有一台 TURN 服务器做中继否则连接永远建不起来。OmniGame 的处理策略是默认带上几个公共 STUN 服务器游戏运行时实时监测连接状态如果建连超时界面提示用户“当前网络需要中继服务器”然后接入我临时配置的 TURN 服务。很多开发者最容易犯的错误是只配 STUN 不配 TURN结果是他们自己家里测试正常一到公司网络或某些大学宿舍网络就翻车。如果你希望兼容最广的玩家群体TURN 几乎不可省略但你可以把它做成可选项只在直连失败时才启动绝大多数情况下根本用不到它。调试 ICE 的最好工具是 Chrome 自带的chrome://webrtc-internalschrome://webrtc-internals它会把 ICE 候选的类型、状态、连接成功的路径全部可视化展示出来。你可以清楚地看到到底是 host candidate 成功了还是 srflx 成功了或者干脆走到了 relay。排查“连不上”问题第一件事永远是打开这个页面看 ICE 状态。4.3 P2P 断线重连比服务器模式难得多WebSocket 模式下重连很简单客户端重新连一次服务器就行。P2P 模式下双方之间的连接断开后如果没有某种中心服务器怎么互相找到对方都是个问题。OmniGame 的做法是两段式先尝试pc.restartIce()协商重连新的 ICE 会让两端重新收集候选在很多临时性网络抖动下都能救回来如果重启失败就直接走“快速重置”——页面上把连接状态重置房间码保持不变双方重新执行一次完整信令流程。对小游戏来说最务实的方案往往是后者。因为大部分网页小游戏是短时对战一群朋友玩一把三五分钟谁掉线了直接刷新页面重新开始是最不伤感情的做法远比费尽心思做到无缝断线续传有意义。如果你的游戏是长局制、半开放世界那我会建议把玩家状态做本地持久化重连后从上次位置恢复到远端但明显这不是小游戏的首要矛盾。4.4 低端机和移动端的性能劫持网页小游戏相当一部分流量来自手机浏览器这个前提直接从根上改变了优化策略。移动端 WebRTC 在低端安卓机上表现尤其挣扎内存紧张时 tab 会被冻结WebRTC 连接可能被系统杀掉iOS 的 Safari 对 P2P 有一些不同的内存回收策略。即使画面渲染正常WebRTC 编码器和 Canvas 同时满负荷运转也可能导致掉帧到 20fps。我把 OmniGame 的渲染策略调成了“自适应分辨率”检测到低帧率就自动降低画布分辨率用 CSS 缩放保证视觉不崩同时把消息发送频率从每帧一次降为每 100ms 合并一次用一次相对大的数据包替换多次小包CPU 占用直接下来一大截。注意这里有一个坑降低分辨率后坐标精度会下降所以编码协议里我给坐标保留了 float32宁可多传几个字节也要保证低分辨率下的位置还是连续的不能一格一格地跳。5. 常见问题与排查技巧实录这一章把所有我在开发与测试过程中遇到的问题集中整理一下做成一个速查表再挑几个最有代表性的坑展开讲。5.1 建连失败速查表现象可能原因解决思路双方都卡在“等待连接”信令没交换成功或 ICE candidate 没传输检查 sendSignal 是否把 host 和 guest 双方候选都发出去Chrome 能连Firefox 连不上mDNS 候选差异或 Firefox 某些 SDP 特性双方都等 200ms 再发 offer或配置统一的数据通道参数公网能连公司网络连不上对称 NAT 或防火墙拦截 UDP必须配置 TURN使用 relay 中继连接建立后几秒断开周期性网络抖动ice restart 失败尝试 pc.restartIce()失败后切换快速重置游戏没声音或画面卡移动端 tab 后台冻结提醒用户保持页面前台或用 visibilitychange 做唤醒处理某些浏览器一直提示“无法建立连接”浏览器设置或插件禁用了 WebRTC检测到 RTCPeerConnection 不可用就给用户提示并回退到简化单机模式这里特别想提醒一句排查 ICE 问题不要猜一定要先看chrome://webrtc-internals。里面会直接告诉你连接类型是 host、srflx 还是 relay连不上时失败原因也写得很清楚。P2P 调试的核心就是“数据看不到但从 ICE 状态能推导出一切”这条逻辑链。5.2 一个让我崩溃的丢包场景早期版本里我用了ordered: false, maxRetransmits: 0的不可靠模式做按键同步结果在做一个节奏类玩法时朋友那边总是漏掉几个按键导致连击断掉。一开始我以为是丢包拼命提高发送频率结果更糟。后来冷静下来分析才发现问题根本不是丢包而是同步策略错了节奏类玩法需要所有玩家以同一个全局时钟为基准判定按键不能靠“消息到达时间”来对齐。解决方法是加一个简单的时间同步主机把自己的时间戳随消息发送客户机计算 RTT 后做相位校正。这样即使个别消息丢了只要后续消息带上正确时间戳下一次按键的位置还是对的。这次踩坑让我记下一个铁律不要指望网络不会丢包要在协议层就把“丢包是常态”这个前提接受下来然后围绕它设计容错。5.3 浏览器兼容性最容易被忽略的一层Chrome 和 Edge 基本一致Firefox 也有自己的性格最难缠的是 iOS 的 Safari 和各类国产浏览器。iOS Safari 从 14.5 之后才慢慢稳定支持 DataChannel 的一些高级特性之前版本偶尔会出现 datachannel 事件不触发的问题国产浏览器的 WebRTC 实现五花八门有的直接阉割有的行为跟标准差异非常大。如果你做的是分享链接传播的小游戏一定要先花半天时间在真实设备矩阵上过一遍。一个值得养成的习惯是所有信令和 RTC 代码统一做一个 capability 检测function supportsP2P() { return typeof RTCPeerConnection ! undefined typeof RTCDataChannel ! undefined; }如果返回 false直接用类似“设备不支持实时联机”的中性提示或者回退到本地双人同屏模式。别等到用户都进来了才发现没有连接能力。6. 影响范围零依赖 P2P 把工程上限推到了哪里标题里那句“重新定义网页小游戏的工程上限”不是口号最后这一章我想正正经经讲讲零依赖 P2P 到底改变了哪些具体指标。6.1 成本模型从“按服务器付费”到“按信令次数付费”做一个最直观的定量对比一个 WebSocket 联机小游戏100 人同时在线需要一台至少 2 核 4G、5Mbps 带宽的云服务器就算最低配一个月也要几百块峰值可能还不够用。OmniGame 走 P2P 后中心服务器做的事情只有信令交换按每个玩家连接一次性交换 10KB 左右的文本算1000 人同时在线一个月信令流量可能都不到 1GB。这基本上意味着游戏运营成本会被压缩到趋近于零剩下唯一的大头只有 TURN 中继的按量计费而且大多数玩家可以直连根本用不到 TURN。我把这个模型叫“按信令次数付费而不是按在线时长付费”。在线时长是持续消耗信令次数是一次性开销前者是乘法后者是加法。这个转变对独立开发和实验性游戏是决定性的。6.2 分发方式被压到了极限一个 HTML 文件就是一款游戏零依赖加单文件让网页小游戏获得了最极致的传播形态一个链接。不需要安装应用不需要扫码下载不需要打开应用商店。分享到群聊里对方点开就能玩部署到任意静态托管一个文件搞定甚至 U 盘里双击就能离线运行。热搜里的“不用下载 app复制链接浏览器打开”其实就是这个模式最精炼的表达。这个传播形态直接改变了获客模型。传统游戏下载是“先安装再体验”转化链路长网页游戏是“先体验再决定要不要继续”而且零依赖意味着没有安装失败、没有系统不兼容、没有版本不匹配所有用户看到的就是游戏本身。6.3 对开发者和玩家生态的连锁影响对开发者来说零依赖 P2P 意味着联机能力从一个后端专项变成了前端基本功。你只要会 JS就能做两个人的实时联机游戏不用学服务器部署、不用买域名备案、不用处理同时在线。很多前端开发者碍于没有后端经验而不敢碰联机游戏这个门槛被 WebRTC 直接拆掉了。对玩家来说拉朋友一起玩的门槛消失是最直观的体验变化。以前想要拉一个人加入游戏得让对方注册、下载、进房间现在只要在微信或群里扔一个链接对方打开就是游戏。任何一点传播门槛的降低都可能让一款小游戏的爆炸式传播机会提升很多倍。6.4 边界和后续扩展方向P2P 也不是万金油。它解决的是“双方都在线且直接交互”这一类场景排行榜、账号体系、离线推送、数据持久化这些仍然是中心服务器的领域。所以 OmniGame 的边界就在这里它是实时对战引擎不是游戏平台。如果要把它扩展成大平台那就在上面再接一层 Serverless 服务用中心服务做房间调度和结算用 P2P 做实时对战两者并不互斥。我接下来的计划是把它做成一个模板化的“零依赖联机游戏骨架”把信令、二进制协议、状态同步、重连这些通用模块提取成可复用的组件每个新玩法只需要关心游戏逻辑本身。另外也在看 WebTransport 的方向它提供更精细的拥塞控制未来可以和 WebRTC 形成更丰富的选择组合。最后说点实在的整套 OmniGame 做下来我收获最大的不是“网页游戏可以做联机”这个认知而是“工程上限是被默认条件锁死的”这个判断。很多项目不是做不到是因为默认了必须用框架、必须买服务器、必须装客户端于是上限就被这些前提限制住了。把每个默认前提都拆下来重新审视一遍往往就能找到一条新的、更轻的路径。最后再分享一个非常实用的小技巧分享链接时把房间号放在 URL 里再加上自动加入逻辑等于玩家零操作进入游戏。你只需要在链接后面加上?roomXXXXXX页面加载后自动解析并触发连接流程。我实测过朋友收到链接后从点击到看到游戏画面通常不超过三秒这个体验门槛比任何引导文案都管用。如果你想给这款游戏更高的开局成功率可以让主机先等对方channel.readyState open之后再发送初始世界状态这样就不会出现有人已经跑起来、有人还没加载完的诡异局面。 我在实际运行中最强的感受就是当你把“零依赖”和“P2P”这两个约束同时放进设计稿里所有模糊的架构问题都会变得出奇清晰——每一个要做出来的东西都必须能回答“没有服务器它怎么跑”“没有框架它靠什么实现”这两个追问。联机的尽头不是一堆云资源而是浏览器本身的能力边界。把边界推到极限之后你会发现它比想象中宽得多。