你有没有收到过那种一段 HTML 直接双击就能玩的网页小游戏？不用安装、不用构建、不用服务端，代码贴在聊天窗口里就能分享，mikutap 就是这类玩意的典型代表。这类零依赖小游戏一直活得很好，传播成本低到令人发指，一个文件就是整个产品。但对工程师来说，“零依赖”看起来是把上限封死了——单机、无状态、没法多人联机。直到我把一条 WebRTC P2P 通道接到这种单文件小游戏上，局面才彻底改观。
这篇博文想聊的核心问题只有一个：一个原本零依赖、单文件、纯前端的网页小游戏，如何在不改变“不给玩家增加任何安装负担”的前提下，跨过多人实时交互这道坎，最终到达 WebRTC P2P 这条工程路径。我会把从零依赖到 P2P 的完整演进过程拆开讲，讲清楚每一步为什么要这么走，以及浏览器这个特殊运行环境给你挖了哪些坑。
1. 零依赖到底意味着什么：单文件游戏的交付红利
很多刚接触网页开发的人会觉得“零依赖”等于“简陋”，这其实是个挺大的误解。零依赖不意味着功能少，它意味着你主动放弃了一套工程化体系，换取了极致的交付自由度。我对零依赖的定义很苛刻：整个项目就是一份 HTML 或者一份 JS 文件，双击就能跑，不需要 Node 环境，不需要装任何包，不需要编译，甚至不需要一个服务器把页面托管起来——直接file://打开也能玩。
1.1 零依赖游戏的“三无”特质与传播优势
这类游戏我习惯叫它“三无游戏”：无构建、无运行时依赖、无服务端。
- 无构建：你写的就是浏览器直接能解析的代码。不用 webpack、不用 babel、不用 TypeScript 编译，甚至不用考虑 ES Module 跨域加载的参数问题，所有逻辑塞在一个
<script>标签里就完事。 - 无运行时依赖：不引 React、不引 Three.js，不依赖 CDN 上的任何公共库。代码里哪怕要用一个复杂算法，也是自己手写实现。这意味着游戏打开的一瞬间，所有需要的代码已经在本地了，没有加载等待、没有外链挂掉的风险。
- 无服务端：没有任何 AJAX 接口、没有数据库、没有登录体系。所有状态存在浏览器内存里，关掉页面就归零。
为什么这种形态到现在还很有生命力？核心是传播成本。一个 mikutap 式的音游，玩家不需要去应用商店下载，不需要注册账号，甚至不需要等加载，发一个链接过去，点开就能玩。这类游戏天然适合私域流量场景：聊天群里丢一个文件、论坛帖子里贴一段代码、网页里嵌一个 iframe。从网页小游戏的运营角度看，“用户从看到到上手玩起来的路径尽可能短”这件事，比任何优化都重要。
我在实际项目里还遇到过一种特别有意思的用法：玩家把一份 HTML 游戏文件复制进浏览器地址栏，浏览器会直接把它当成 data URL 渲染出来，连文件都不用下载。这个玩法的前提就是单文件依赖权重足够低，所有引用都是相对路径或内联内容。只要你往工程里加了一个外部脚本引用，这套交付能力就废了。
1.2 单文件交付的工程天花板：单机隔离
零依赖的代价也很明显，那就是每个玩家的浏览器都是一个孤岛。你没法知道别人在玩什么，别人也没法进入你的游戏世界。单机小游戏可以是完美的单机体验，但人类对实时互动的需求是刻在骨子里的——俄罗斯方块能双人对战、节奏游戏能同步打拍、飞行射击游戏能同屏乱斗，这些都比单机高一个量级。
要让两个浏览器里的游戏状态互通，从工程角度只有两条路：一条是走中心服务器转发，你维持一台有公网 IP 的机器，所有玩家的操作都上报给它，再由它广播给其他人；另一条就是 P2P，让浏览器之间直接建立连接，数据不过第三方。第一条路对“零依赖”是毁灭性打击：你得为每个游戏单独部署服务端，还得为带宽买单。第二条路看起来诱惑力极大——浏览器原生就有 WebRTC 能力，关键在于怎么把它和零依赖的小游戏工程无缝拼接起来。
2. 为什么是 WebRTC：P2P 数据通道解决了中心服务器的三道坎
如果只是要实现联机，其实很多团队会下意识选中心服务器方案，毕竟 WebSocket 是入门门槛最低的实时通道。但站在网页小游戏的场景里仔细算账，中心转发的模式有三道绕不过去的坎。
2.1 中心服务器模型的成本痛点
第一道坎是带宽成本。实时游戏和聊天不一样，一局 4 人联机的飞行射击游戏，每帧都要广播位置、旋转角、操作状态，按 30Hz 算，单玩家每秒可能要产生十几个小报文，所有玩家乘起来，一个房间的带宽消耗并不低。做个小范围的朋友联机游戏，服务器带宽成本可能比研发成本还高，这在小游戏这个“轻量级”赛道里很不划算。
第二道坎是网络延迟。中心服务器的路径是“玩家 A → 服务器 → 玩家 B”，延迟取决于 A 到服务器再到 B 的累计往返。如果服务器部署在某一个城市，那跨区域的玩家必定有一方要吃高延迟——这在需要精确帧对齐的实时小游戏里是灾难级的体验问题。
第三道坎是开发复杂度。你自己维护一套房间管理、消息路由、断线处理的服务端逻辑，再加上鉴权、限流、日志，本质上你变成了一个游戏后端团队。对样式是“一个 HTML 文件交付”的项目来说，这套重量级基础设施完全是不可承受之重。
2.2 WebRTC DataChannel 的工作原理与选型依据
WebRTC 当初被设计出来的动机是视频通话，但真正让游戏开发者兴奋的是它的数据通道（DataChannel）能力。DataChannel 走的是 SCTP over DTLS over UDP，不了解细节没关系，你只需要知道三点：
- 它能让两个浏览器之间建立一个直接的数据通道，数据不需要经过任何中转服务器。
- 它同时支持“可靠有序”和“部分可靠无序”两种传输模式。前者像 TCP，每条消息保证到达、保证顺序，适合传输关键状态；后者像 UDP，允许丢包和乱序，但延迟低得多，适合传输实时性要求极高的操作输入。
- 连接建立之后，信令服务器就不再参与数据传输了。信令服务器只在握手阶段帮忙交换连接信息，握完手就可以把路让开。
我用一个生活化类比：WebRTC 的信令过程就像两个人借手机打电话之前，先用短信把自己的号码发给对方，等真正通话开始，短信通道就没用了，语音走的是运营商通信网。这里的“运营商通信网”就是浏览器之间直接建立的 P2P 通道。
在零依赖小游戏这个场景里选 WebRTC 而不选 WebSocket，最直接的理由就是：部署形态依然是浏览器原生能力，不需要云主机，不需要运维。如果你愿意，信令部分也可以做成纯客户端手动交换，后面我会讲到。
2.3 RTCPeerConnection 与 DataChannel 的最小接入
我最早接入 WebRTC 时用的是 PeerJS 这类封装库，确实省事，但它有两个问题：一是引入了外部依赖，会破坏零依赖的纯洁性；二是很多细节被封装掉了，出了问题无从下手。后来我直接基于原生RTCPeerConnection写了一版最小接入，代码量其实也不算大。
// 极简 WebRTC DataChannel 接入骨架（未含完整信令流程） const peer = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] }); peer.onicecandidate = (event) => { if (event.candidate) { // 将候选者信息通过信令通道发给对端 signalingSend({ type: 'candidate', candidate: event.candidate }); } }; const channel = peer.createDataChannel('game', { ordered: false, // 游戏操作通道优先低延迟 maxRetransmits: 0 // 不重传，丢了就丢了 }); channel.onopen = () => { // 连接建立，可以开始互发游戏消息 }; // 对端通过信令送来 SDP 后 await peer.setRemoteDescription(new RTCSessionDescription(remoteOffer)); const answer = await peer.createAnswer(); await peer.setLocalDescription(answer); signalingSend({ type: 'answer', sdp: answer });这套骨架跑通之后，我做的第一件事就是验证延迟。实测同城局域网环境下 DataChannel 的往返延迟基本在 1ms~5ms 量级，跨网络公网环境在 20ms~50ms 量级，相比中心服务器转发路径，敏感度明显不同。这里有个经验性的结论：如果你的游戏操作复杂度到了“每帧都需要交换状态”的程度，P2P 的数据通道是浏览器里性价比最高的方案，没有之一。
3. 从单机到多人，先过架构关：确定性逻辑与渲染的彻底分离
我在做第一个 P2P 联机版本时犯过一个非常典型的错误：把原本单机游戏里的输入逻辑、状态更新、Canvas 绘制全都混在同一个requestAnimationFrame循环里，然后试图在循环里“顺便”把玩家操作发给对端。结果是画面卡顿、状态错乱、联机双方看到的东西完全不一致。
这次惨痛经历让我意识到一个关键前提：P2P 联机改造的第一步不是网络，而是单机代码的架构。如果你没有把“游戏逻辑”和“渲染”拆开，后面一切同步方案都无从谈起。
3.1 为什么多人实时必须具备可重放的逻辑核心
P2P 模式下没有中心服务器替你仲裁，所有参与方本质上是在各自浏览器里“跑同一个游戏”。要让多方看到同一个世界，必须保证大家跑的逻辑是同一套、输入的顺序是一致的。这就意味着游戏的核心逻辑必须确定：同样的输入序列，无论在哪台机器上跑、无论跑多少遍，产出的状态必须完全一致。
确定性的前提是逻辑与表现分离。一个典型的反模式是：逻辑代码里直接调用 DOM API 或 Canvas 绘制方法，或者直接读取Date.now()/Math.random()来决定游戏行为。这些都会让状态变得不可复现。正确的做法是：把游戏世界建模成一个“状态机”，它只依赖输入事件和时间步长来推进，渲染层只是这个状态机的显示器。
3.2 状态机 + 输入队列的最小设计
我给自己定了一个简单但严格的分层规范：
- 逻辑层：一个纯函数
reducer(state, inputEvents) -> newState，不访问任何浏览器 API、不产生任何 IO、不调用随机函数。 - 输入层：玩家按键、点击、摇杆操作统统转换成标准的事件对象，统一塞进一个输入队列，由逻辑层按顺序消费。
- 渲染层：每帧读取逻辑层产出的状态，画出画面，但绝不反向修改状态。
一个简化的思路是参照 Redux 的 reducer 模式。游戏每帧推进时，拿这段时间累积的操作事件列表去更新状态。我后来把这些事件在联机时原样发给对端，对方也在本地执行相同的状态更新，从而实现“所见即所得”。
// 逻辑核心：全局状态 + 纯函数更新 const initialState = { players: [], bullets: [], frame: 0 }; function gameReducer(state, events) { let next = structuredClone(state); for (const ev of events) { if (ev.type === 'MOVE') { // 根据方向键更新玩家坐标，纯数学运算，不碰 DOM const player = next.players.find(p => p.id === ev.playerId); player.x += ev.dirX * PLAYER_SPEED; player.y += ev.dirY * PLAYER_SPEED; } if (ev.type === 'SHOOT') { next.bullets.push(createBullet(next.players.find(p => p.id === ev.playerId))); } } next.frame += 1; return next; }需要说明的是，structuredClone只是便于演示，实际项目里我会用更节省内存的方式做不可变更新。但原则是明确的：状态结构不能有多份拷贝、更新路径不能被外部变量干扰。
3.3 主机权威 vs 全量帧同步的架构选择
逻辑分离做完之后，接下来要回答一个更根本的问题：联机时谁是权威？在小游戏场景里，常见的选择有两种。
- 主机权威模式：一个玩家成为主机，所有人的操作都发给主机，主机计算世界状态后广播给所有人。其他客户端只是“远程显示器”。
- 全量帧同步（Lockstep）：每个玩家手里都有一份完整的世界副本，大家按照统一的帧号执行相同的输入序列，状态天然一致，主机只负责汇集和广播操作序列。
从开发难度上说，主机权威模式更好做，因为它能容忍不同客户端的性能差异，也不需要纠结浮点一致性。但从延迟和流量上说，帧同步模式明显更优——它广播的是“输入”而不是“状态”，数据量小一个量级。
对小游戏这种 2~8 人、操作频繁、状态简单的场景，我最终的推荐是：先做主机权威，跑通完整玩法；等需要做 4 人以上同屏高频交互时，再升级到帧同步。不要在一开始就挑战高难度。
4. 帧同步上线的关键细节：时间对齐、浮点陷阱与回放方案
如果你选择了帧同步模式，恭喜你，接下来要面对的是实时对战的“细节地狱”。帧同步的理论很简单——大家跑同一个确定性模拟，难点在于让接收端的本地模拟和对端保持在同一个时间基准上。
4.1 帧号与操作时间戳的配合
我的做法是给游戏定义一个固定的逻辑帧率，例如每秒 30 帧。每个帧都有一个全局递增的帧号。所有玩家操作产生后不是立刻执行，而是先放进待发送队列，由主机收集一帧内的所有操作，打包成一个“指令块”，广播给所有客户端。每个客户端拿到指令块后，把它追加到本地输入队列里，然后逐帧消费。
这套流程里最容易出问题的点是：不能直接消费“刚刚收到”的指令块，而是要根据帧号对齐。如果 A 玩家的网速比 B 玩家快，B 那边可能已经落后 5 帧了。处理办法是给每个客户端维护一个提前量缓冲：保持本地逻辑帧进度比最新收到的主机指令块慢 2~3 帧，用缓冲来消化网络抖动。我实际测试下来，缓冲 100ms 左右能很好地平衡实时性和流畅度。
4.2 跨端确定性：浮点数是个深水区
帧同步有一个隐蔽的深坑：同一个数学计算在不同浏览器、不同设备上可能得到不同的结果。听起来不可思议，但事实是Math.sin、Math.sqrt、Math.pow这类浮点运算函数，不同平台的实现方式是允许有细微差异的。在单机环境里差异完全无感，但在帧同步联机场景里，初始状态哪怕差出 1e-10，经过几千帧迭代后也可能被放大成肉眼可见的偏差。
我踩过这个坑之后，给项目定了三条规矩：
- 尽量用整数运算。坐标、速度、碰撞检测，能不用浮点就不用浮点，全部乘上 1000 变成整数处理，做完除法后直接取整。
- 自己实现关键数学函数。像碰撞检测里的矩形相交、圆的碰撞，不要依赖框架封装结果不定的算法，手写逻辑，保证所有端跑同一份代码。
- 随机数必须可控。游戏里任何随机事件都由一个确定性种子生成随机序列，序列放在共享状态里，所有机的随机数表现完全一致。
这三条规矩加上纯函数 reducer，可以保证帧同步在绝大多数主流浏览器上都能稳定复现同一局游戏。顺便提一句，这也带来了一个额外的福利：回放功能几乎零成本。因为游戏是确定性状态机，你只需要记录每一帧的输入序列，就能完整重放一局游戏的全程，这对测试联机同步正确性、复现玩家反馈的 BUG 都极其有用。
4.3 慢客户端与断线重连的处理策略
帧同步对“猪队友”很敏感。有人机器卡了 500ms，整个房间的模拟都会被拖慢。我的处理策略是：主机不再无条件等待最慢客户端，而是当某个客户端连续 3 帧没有上报操作时，把它标记为“暂离”，主机的指令块里对应帧的输入空缺用“保持上一帧操作”填充，同时在别人画面上给它显示出“网络不佳”的角标。这个策略省去了复杂的同步等待机制，工程上简单得多。
断线重连是另一个准备功夫。小游戏通常不追求像竞技游戏那样毫秒级的重度体验，我的方案是：断线玩家重新加入时，主机给它下发一份“全量世界快照”，客户端载入快照后，再通过“从该帧号开始回放后续输入序列”来追回实时状态。快照加回放组合拳，比实时同步更可靠，也避免了掉线重连后世界不一致的问题。
5. 信令与部署的取舍：最少服务的 P2P 落地路径
WebRTC 有一个绕不开的前提：两个浏览器要建立 P2P 连接，必须先交换一次“联系方式”——也就是 SDP 和 ICE 候选信息。这个过程需要一条事先存在的通信链路，业内把它叫做信令通道。问题来了：零依赖游戏要维持零依赖，信令通道哪里来？
5.1 信令服务为什么省不掉
信令服务不是数据传输的一部分，它只是“牵线搭桥”。但桥不能省，因为浏览器无法凭空发现另一个浏览器的地址。P2P 的“P”是 Peer，前提是你知道 Peer 在哪里。
我有两个层次的解决方案：
第一层是部署一个极简信令服务。这个服务不参与游戏数据转发，只帮忙做三件事：创建房间、交换 SDP 与 ICE 候选、通知玩家进出房间。它对外只暴露一个 WebSocket 端点，甚至不需要数据库。如果你嫌写服务端代码麻烦，也可以用现成的公共信令服务。
第二层是手动信令。这个方案特别适合零依赖的极客场景：游戏页面里内置一个“生成连接码”按钮，点击后把本端的 SDP 信息压缩成一段短文本，玩家把这段文本复制发给另一个玩家，另一个玩家粘贴到游戏里，双方就完成了握手。这个流程完全是离线的、可人工操作的，且保留了零依赖的纯度。
5.2 手动信令的完整连接流程
手动信令我用得非常多，因为它在开发者调试阶段特别高效。具体流程是这样的：
- 玩家 A 点击“创建房间”，页面生成一个
offerSDP，同时把本端 ICE 候选收集起来，然后页面显示一段编码后的文本。 - 玩家 A 把这段文本复制，通过任何聊天工具发给玩家 B。
- 玩家 B 点击“加入房间”，粘贴玩家 A 的文本，页面解析后生成
answerSDP，也显示一段编码后的文本。 - 玩家 A 把玩家 B 的 answer 文本复制回来，粘贴进游戏页面，双方连接建立。
手动信令的唯一缺点是流程冗长、对普通玩家不友好。但它的价值在于：它向所有开发者证明了，WebRTC 联机完全可以不依赖任何可用的后端服务。在纯局域网环境、没有外网服务器的情况下，这套方案是最后的兜底。
5.3 把信令伪装成“分享链接”的传播设计
手动信令虽然工程上是闭环的，但玩家体验太差了。为了让玩家侧的使用习惯匹配零依赖游戏的传播属性，我做了一个折中方案：游戏会生成一个包含 SDP 信息片段的长链接（<a href="https://.../#room=xxxx">），玩家只需把链接发给朋友，朋友点开链接后，浏览器解析location.hash里的信息，自动发起 WebRTC 连接。
这个方案把信令过程包装成了网页游戏的“分享”动作，和零依赖小游戏“复制链接给朋友”的传统操作习惯一致。唯一需要注意的是哈希片段里塞不了太大的 SDP，所以我对 SDP 做了精简，只保留必要的音视频无关的 data channel 字段，必要时用 ICE 候选慢慢补全。实测下来，一条连接码压缩到 1KB~2KB 以内毫无压力。
5.4 生产环境的最轻部署形态
当游戏真正面向公众发布时，我还是会部署一个最简单的信令服务器，但它极其轻量，一个 DAAS（Database as a Service）都大不了，一个无状态 Node 进程足以。部署形态是这样的：
- 游戏本身：继续以纯静态 HTML+JS 输出，放到任意 CDN 或对象存储上，不需要业务后端。
- 信令服务：一个只做 WebSocket 导播的轻量进程，逻辑只有十几行，负责把一个人的 SDP 转交给同房间的另一个人。
- 游戏数据通道：玩家之间直接走 WebRTC DataChannel，不碰信令服务器。
这个部署形态的月成本基本可以忽略不计，和传统中心服务器方案动辄按带宽计费的账单不是一个量级。而且因为数据通道不经过你的服务器，你根本不需要为游戏流量的增长去扩容服务器——这是 P2P 架构最吸引人的地方：玩家的网络资源就是你的基础设施。
6. 浏览器环境下的 WebRTC 调试与坑位记录
最后这部分我想集中讲讲实战里一定会遇到的坑。WebRTC 是浏览器能力，但浏览器对 WebRTC 的支持细节千差万别，稍不注意就会踩进去。我建议所有做 P2P 联机小游戏的人都先学会一个技能：看懂 WebRTC 体检报告。
6.1 用 chrome://webrtc-internals 做连接体检
Chrome 浏览器内置了一个 WebRTC 的调试面板，地址是chrome://webrtc-internals。很多人不知道这个工具的存在，但它对排查 P2P 连接问题的重要性，堪比 X 光机之于骨科医生。它能显示你当前所有RTCPeerConnection的 ICE 连接状态、候选者类型、RTT 往返时延、收发字节数、以及 DataChannel 的状态变化。
实测经验：如果联机卡顿，先看这个面板里的RTT数值；如果持续超过 200ms，说明连接路径绕远了，ICE 没有选中最优路径，大概率是 NAT 穿透没打洞成功，落到了 TURN 中继回退上。如果面板里看到relay类型的候选者被选中，就说明你的 P2P 已经退化成了中心服务器转发，这时候需要重新审视 STUN 配置和网络环境。
6.2 消息大小、mDNS 候选与后台节流
接下来是三件我几乎每次项目都会遇到的坑。
第一个是数据通道消息大小限制。DataChannel 底层走 SCTP，虽然协议本身支持较大的消息块，但浏览器实现和流控机制并不希望你发大块头。我在项目里规定：单条 DataChannel 消息不要超过 64KB，能拆就拆，能不一次性发送就不要一次性发送。超过这个量级，轻则触发 SCTP 背压导致延迟陡增，重则让 DataChannel 缓冲区爆掉，表现为消息卡死、连接假死。游戏里需要传输全量快照时，我都是先拆成两个包，接收端合并在一个完整帧里处理。
第二个是 mDNS 候选导致的局域网连接变慢。新版 Chrome 出于隐私保护，在本机候选者里默认使用.mDNS.local形式的匿名主机名代替真实 IP，导致局域网联机时 ICE 连接建立时间明显变长。你让两个设备在同一 WiFi 下联机，可能要多等两秒才能连上。如果你做的是线下聚会型的多人小游戏，一定要在配置里显式带上iceCandidatePoolSize，或者提示玩家使用同一网络时切换候选策略，能显著缩短连接时间。
第三个是浏览器后台标签页节流。桌面浏览器在标签页切换到后台后，会大幅降低定时器的执行频率，requestAnimationFrame直接停摆。而帧同步游戏最忌讳的就是客户端“偷懒”，后台的客户端一旦参与联机，会造成整局的模拟节奏漂移。我的处理是：全局通过 Page Visibility API 监听页面可见性，一旦发现某玩家切了后台，立即暂停本端的逻辑帧推进，并向其他端广播“暂离”状态。这比让另一个端迁就它的迟缓要诚实得多。
6.3 不同浏览器的兼容性清单
目前主流的 Chrome、Edge、Firefox、Safari 都支持 WebRTC DataChannel，但细节差异依然存在。Safari 对 DataChannel 的缓冲策略偏保守，高频率小消息推送时偶尔会出现消息积压；Firefox 的 ICE 候选收集速度在部分网络环境下偏慢；手机端的移动浏览器则受锁屏、切后台限制，网络稳定性最差。
我会在项目里维护一张兼容性矩阵表，用来自测：
| 浏览器 | DataChannel 可靠有序 | 部分可靠模式 | 备注 |
|---|---|---|---|
| Chrome / Edge | 正常 | 正常 | 首选项，调试体验最好 |
| Firefox | 正常 | 正常 | ICE 收集偏慢，候选需耐心等 |
| Safari | 正常 | 支持有限 | 大消息时注意缓冲积压 |
| 移动端 Safari | 正常 | 支持有限 | 锁屏/切后台大概率断连 |
我的建议是：把 Chrome/Edge 当主开发环境，Safari 做成兼容性测试线，Firefox 作为候选自测环境。每次发布前跑一遍这 4 个环境，能筛掉 80% 的兼容性问题。
6.4 联机质量的测试与验收方法
最后分享一套我自用的联机质量验收清单，不需要复杂工具，用浏览器 DevTools 的 Network 面板加 WebRTC internals 就能执行：
- 双机同网联机测试：验证局域网路径是否正常建立 P2P，RTT 应在 10ms 以下。
- 公网跨网联机测试：两台设备分别挂不同运营商网络，验证 STUN 打洞效果，RTT 超过 100ms 时游戏操作是否依然可感。
- 弱网模拟测试：用 DevTools 的 Network 面板手动加 300ms 延迟和 5% 丢包率，观察游戏是否卡死、是否出现状态不同步。
- 一台设备断网测试：主机或客户端强制断网，观察另一端的处理是否优雅，重连后是否能恢复。
- 长时间压力测试：让双方挂机 30 分钟以上，观察内存占用是否持续增长、DataChannel 是否因为大消息积压而假死。
这套清单看起来简单，但每次都能在发布前抓出一堆“单人模式下根本发现不了”的问题。P2P 联机的确定性问题、时间对齐问题、网络质量问题，全部要靠这些真实场景去验证，不能靠拍脑袋。
如果你正在做的也是一个零依赖的单文件小游戏，而你又想让它拥有真正的联机能力，我的切身体会是：WebRTC P2P 这条路一点也不比上服务器方案更难走，反而因为避免了带宽和运维的包袱，让工程上限被真正抬高了一截。浏览器是个约束很多的环境，但正是这些约束，逼着你把逻辑拆干净、把架构想清楚。到最后你会发现，所谓的“重新定义网页小游戏的工程上限”，不是靠什么黑科技，而是靠一步一步把确定性、实时性和交付性做扎实。如果哪天有人拿着你的单文件小游戏问“能不能联机”，你可以告诉他：能，而且不用装任何东西。
