零依赖+WebRTC P2P，打造免服务器的网页小游戏

最近在独立游戏群里看到有人问：为什么 mikutap 这类音乐互动网页，不用装任何东西，复制链接到浏览器就能玩，手感还那么流畅？没过多久，又有人追问“webrtc怎么关闭”，说是不小心授权了浏览器权限，担心隐私问题。这两个问题放在一起，恰好点出了我今天想聊的 OmniGame 项目在做的事：一边把网页小游戏拉回零依赖的原生形态，一边用 WebRTC P2P 把联机能力塞进这种轻量工程里。我想借这篇文章，把从架构选型到落地实现的全过程拆开讲清楚，也聊聊哪些决策是因为踩了坑才改的。

先交代一下背景。OmniGame 是我业余时间维护的一套网页小游戏工程方案，核心约束只有两条：不引入任何第三方运行时依赖，不引入任何构建步骤。在这个基础上，再用 WebRTC DataChannel 实现免服务器的 P2P 实时联机。听起来像是自找麻烦，但一年做下来，我反而觉得这条路对小游戏这个体量来说，是把工程复杂度压到最低、同时把体验上限拉高的一种组合。

如果你也想过“能不能不用 React、不用 Vite、不用 Node 服务，做一个打开即玩还能联机的小游戏”，那这篇文章应该对你有用。我会尽量把原理讲明白，把代码贴到位，再把那些文档里不会写的坑也一并说出来。

1. “零依赖”不是复古，是给小游戏重新算的一笔账

1.1 没有 node_modules 的项目反而更轻快

先说说我为什么一开始就盯上零依赖。几年前我做过一个浏览器小游戏 Demo，技术选型很正常：PixiJS 做渲染，Webpack 打包，Socket.io 做联机。结果项目还没写完，依赖树里已经躺了几百个包。最难受的不是安装慢，而是升级一个依赖经常牵连出一串兼容问题。后来那个 Demo 因为工作太忙搁置了，半年后想再捡起来，发现好几个依赖已经大版本换代，配置怎么调都跑不顺。

OmniGame 的起点就是对这个状态的反思。对于小游戏这种体量——单局时间几分钟、玩法机制相对固定、画面以 2D 为主——重型引擎和构建工具提供的能力，很多其实是用不上的。你需要的可能只是一个稳定的游戏循环、一套输入响应、一组音频调度，再加一个能跑通的状态同步协议。这些用浏览器原生 API 完全可以覆盖。

我把两种方案做了个对照，你可以直观感受下差别：

最直观的体感是调试。没有打包器之后，我改完代码刷新浏览器就能看到结果；排查性能也不再需要翻框架源码。零依赖带来的不是“回到过去”，而是把工程复杂度里最不可控的那部分删掉了。

1.2 零依赖的边界：哪种项目不适合这么干

但这里得说句公道话，零依赖不是银弹。如果你要做的是大型 RPG、3D 场景、有复杂物理系统的项目，那成熟的引擎和构建体系会帮你省下大量时间，不要为了“零依赖”而零依赖。

我的判断标准很简单：看项目的“生命周期负载”。如果一个游戏玩法边界清晰、体量适合单文件承载、预期生命周期长，那零依赖的收益就很明显——因为代码库完全自持，不存在上游断档的问题。反过来，如果玩法还在快速迭代、需要大量美术资源热更新、有复杂的多人管理后台，那还是老老实实用工程化方案。

OmniGame 选择零依赖作为底线，核心原因是它想验证一个命题：网页小游戏能不能做到“复制即玩、代码可审、联机无服务器”。这个命题本身就把工程复杂度逼到了极限，再用框架反而是对目标的稀释。

2. OmniGame 的内核组织：一个浏览器原生能力拼出的游戏本体

2.1 项目骨架与模块拆分

零依赖不等于一个 HTML 文件里堆一万行代码。我用的是浏览器原生 ES Modules，在index.html里通过<script type="module" src="./src/main.js">引入。整个项目的目录结构是这样的：

omni-game/ ├── index.html ├── src/ │ ├── main.js # 入口：初始化引擎与场景 │ ├── engine/ │ │ ├── loop.js # 游戏循环（requestAnimationFrame） │ │ ├── input.js # 键盘/鼠标/触摸统一封装 │ │ ├── audio.js # 基于 Web Audio API 的音频封装 │ │ ├── scene.js # 场景管理与生命周期 │ │ └── math.js # 常用数学工具 │ ├── game/ │ │ ├── world.js # 游戏世界状态 │ │ ├── player.js # 玩家逻辑 │ │ └── render.js # Canvas 2D 渲染 │ └── net/ │ ├── signaling.js # 信令通道 │ ├── peer.js # RTCPeerConnection 封装 │ └── protocol.js # 联机消息协议 └── assets/ ├── images/ └── audio/

这个结构没有任何第三方的影子，但模块边界依然是清楚的。关键是：ES Modules 本身就是浏览器原生能力，所以import语句在开发时直接可用，不需要打包器转译。等到发布时，再通过一个简单的脚本把所有模块拼成单文件，这部分我会在第 6 节详细说。

2.2 游戏循环与输入处理

游戏循环是每个游戏的心脏。OmniGame 的循环实现就藏在engine/loop.js里，核心思路是固定时间步长：

// engine/loop.js export class GameLoop { constructor(update, render, fixedStep = 1 / 60) { this.update = update; this.render = render; this.fixedStep = fixedStep; this.accumulator = 0; this.lastTime = 0; } start() { this.lastTime = performance.now(); requestAnimationFrame(this.tick.bind(this)); } tick(now) { const delta = Math.min((now - this.lastTime) / 1000, 0.1); this.lastTime = now; this.accumulator += delta; while (this.accumulator >= this.fixedStep) { this.update(this.fixedStep); this.accumulator -= this.fixedStep; } this.render(now); requestAnimationFrame(this.tick.bind(this)); } }

delta做了 0.1 秒的上限钳制，这是防止标签页切回来时物理逻辑瞬间跳一大段。固定时间步长则保证了联机环境下逻辑确定性——这在后面 WebRTC 状态同步里会变成刚需。输入模块我统一封装了键盘、鼠标和触摸事件，对外只暴露一个简洁的状态接口：

// engine/input.js export const Input = { keys: new Set(), pressed: new Set(), mouse: { x: 0, y: 0, down: false }, attach() { window.addEventListener("keydown", (e) => { if (!this.keys.has(e.code)) this.pressed.add(e.code); this.keys.add(e.code); }); window.addEventListener("keyup", (e) => { this.keys.delete(e.code); }); // 鼠标与触摸事件类似，略 }, consumePressed() { const set = new Set(this.pressed); this.pressed.clear(); return set; }, };

注意加圈的细节：this.pressed是“按下瞬间”的集合，每帧消费一次后清空。小游戏里很多操作要求的是“边界触发”而不是“持续触发”，直接用keys集合会漏掉那些一帧内发生又结束的按键。

2.3 图片、音频资源怎么裸加载

没有打包器之后，资源加载要回归浏览器原生的方式。图片用new Image()加 onload 事件，音频走 Web Audio API 的fetch + decodeAudioData。直接看代码：

// engine/audio.js export async function loadAudio(url) { const res = await fetch(url); const arrayBuffer = await res.arrayBuffer(); const audioContext = getAudioContext(); const decoded = await audioContext.decodeAudioData(arrayBuffer); return decoded; }

这里有个很关键的坑：Web Audio API 的AudioContext在页面加载时是suspended状态，必须等到用户手势触发后才能resume。这是浏览器的自动播放策略，mikutap 这类音游能“一点就响”，也是因为它的首次交互事件里调用了ctx.resume()。

我对这个问题的处理方式是：把getAudioContext的调用延后到第一次键盘或触摸事件，然后在同一事件里立即 resume。不要放在DOMContentLoaded里面，否则你会看到页面加载完没有任何声音，直到用户第一次点击才恢复。

图片和音频的加载进度管理，我写了一个极简的 Promise 计数器，统一在main.js里等待所有资源就绪再启动场景。加载失败的资源会重试一次，再失败就用内置的占位图保证游戏不白屏。

3. 单机到联机：为什么我把注下在 WebRTC P2P 上

3.1 WebSocket 服务器方案的问题在哪

先说说传统方案。用 WebSocket 做实时联机，逻辑上很好理解：所有客户端连到一台中心服务器，服务器负责转发消息。对聊天室来说这个模式天经地义，但放到小游戏里会碰到几个痛点。

首先是延迟和地域问题。你的服务器只能部署在某几个地域，玩家分布在不同城市时，消息要绕到服务器再回来，相当于走了两段公网链路。如果两个玩家本身很近，却因为服务器在远方而白白增加几十毫秒延迟，这对动作类小游戏是致命的。

其次是成本问题。哪怕游戏逻辑再简单，只要联机就得有人付服务器的带宽钱。房间数量一多，每月的流量账单会很可观。而 P2P 模式下，服务器只承担最初的“牵线”职责，游戏数据进行玩家间直连，流量成本几乎归零。

最后是容灾问题。中心服务器宕机，全部玩家掉线；P2P 环境下某个玩家断线，影响的只是那一局比赛。对小游戏这种“轻量、多局、随开随玩”的形态来说，去中心化明显更贴合使用场景。

3.2 WebRTC DataChannel 的带宽、延迟与穿透

WebRTC 这套协议，大家接触最多的场景可能是语音视频通话，但它的DataChannel能力才是做游戏联机的核心：可以语义上把它理解为一个浏览器原生的、低延迟的 P2P 消息通道。它支持两种传输模式：可靠有序（类似 TCP）和不可靠无序（类似 UDP）。游戏里的位置同步、操作指令这些对时效要求高、对偶发丢包容忍度高的消息，就该走不可靠模式。

关于延迟和带宽，我直接说我的实测数据。两台在同一座城市、网络状况正常的机器之间，DataChannel 的 RTT 通常在 20-50ms 之间，跨省网络大概在 60-100ms。带宽方面，传递小体积 JSON 消息时，每秒 30 条、每条几十字节完全不是问题；即使推 60fps 的高频输入采样也足够。关键在于消息不要设计得太肥，这个后面讲协议时再展开。

穿透方面，WebRTC 内部整合了 STUN 和 TURN 机制。STUN 负责在绝大多数 NAT 环境下找到公网连通路径；TURN 则是在对称型 NAT 或严格防火墙环境下，退化为服务器中转。我在实际测试中发现，典型的家庭宽带 + 手机 4G/5G 网络组合，P2P 连接成功率大约在 85%-90%；剩余约 10% 的场景需要 TURN 兜底。这也就解释了为什么“完全免服务器”在理论上不成立——信令和 TURN 兜底里至少需要一个轻量服务。

3.3 隐私问题：为什么有人想“关闭 WebRTC”

既然提到 WebRTC，就躲不开隐私争议。这也是网上总有人搜“webrtc怎么关闭”的原因——WebRTC 在建立连接时会探测本机所有网卡地址，然后把本地 IP 通过 ICE 候选发送给对端。在某些环境下，这会让用户暴露内网 IP 甚至经过 NAT 映射后的公网 IP，于是不少浏览器用户出于隐私考虑选择直接禁用 WebRTC。

对游戏开发者来说，这个问题要从两端看。一端是尊重用户选择：确实有一部分玩家会主动关闭 WebRTC，意味着你的游戏必须对这一小部分人给出降级方案。我在 OmniGame 里做了个设置项，允许玩家选择“仅通过中继”模式，连接时只使用 TURN 候选，不直连，牺牲一点延迟换隐私安心。

另一端是技术上的缓解手段。现代浏览器其实已经在做一件事：通过 mDNS 对 ICE 候选中的本地 IP 进行混淆，让对端看到的是一串.local域名而不是真实 IP。在 Chrome 和 Firefox 中，默认策略已经部分启用。我自己在信令服务器上做了脱敏处理——转发 ICE 候选前把本地 IP 字段去掉、只保留公网候选，这样信令层面就不会泄露内网地址。

4. 免服务器联机的完整落地：信令、房间与状态同步

4.1 信令服务只干一件事：牵线

前面已经提过，WebRTC 本身不负责“怎么找到对方”，这一步要由信令机制完成。我在 OmniGame 里最轻量的做法是：一个只有几十行的 WebSocket 服务，唯一的职责是帮忙转递 SDP 和 ICE 候选。游戏数据本身不走这个通道，所以它几乎不消耗带宽。

信令交互的流程是这样的：

1. 房主创建一个RTCPeerConnection，用createOffer()生成 Offer SDP。
2. 房主把 Offer 发给信令服务，服务广播给房间内的其他玩家。
3. 加入者收到 Offer 后，用setRemoteDescription()设置远端描述，再调用createAnswer()生成 Answer，回传给房主。
4. 双方不断通过onicecandidate回调和信令转发交换 ICE 候选，最终找到可用链路。
5. datachannel事件触发或ondatachannel建立后，游戏通道就绪。

这个流程我前后调试了很久，最常出的岔子是两个：一个是一方还没执行setRemoteDescription就急着给对端发候选，结果对端报错；另一个是 ICE 候选收集还没完成就开始了游戏逻辑，导致出现 3-5 秒的“黑洞期”。最后我统一加了一个“就绪握手”步骤：任何一方要等到iceConnectionState变成connected之后再进入游戏，不然就停留在房间等待界面。

4.2 房间与连接生命周期

房间协议我设计得尽量简单，只定义了几种消息类型：

// net/protocol.js export const MsgType = { HELLO: "hello", // 加入房间 OFFER: "offer", // 信令：SDP Offer ANSWER: "answer", // 信令：SDP Answer ICE: "ice", // 信令：ICE候选 START: "start", // 房主开始游戏 IN: "input", // 玩家输入 STATE: "state", // 状态同步 PING: "ping", // 延迟探测 PONG: "pong", // 延迟回应 EXIT: "exit", // 退出房间 };

房间的生命周期很清晰：房主创建房间后，其他人通过房间码加入。房主决定何时开始游戏、何时解散房间；加入者中途掉线则从状态列表中移除，其他人继续正常游戏。

有个细节值得提醒：房主的RTCPeerConnection在创建时要预先创建一个DataChannel（调用createDataChannel），加入者那边则是监听ondatachannel事件拿到同一个DataChannel实例。不要两头都去创建，否则会出现两个通道，逻辑上很难处理。

4.3 游戏数据的同步策略与断线重连

状态同步策略上，我选择了“房主主机权威”模式。具体说就是：所有玩家的输入都发给房主，由房主的游戏实例更新世界状态，再定期把权威状态广播给所有客户端。客户端这边的表现是“本地即时响应 + 服务器校正”，这能保证大部分时候手感没问题，又不会让各客户端的分歧越拉越大。

同步消息的格式，我只传增量变化而不是全量状态。为了压榨带宽，我把每帧的状态打包成一个紧凑数组，例如：

// 伪代码，示意增量同步内容 { t: 1712345678901, // 游戏时间戳 players: [ { id: 1, x: 12.3, y: 5.6, vx: 0.1, vy: 0.2, a: 45 }, { id: 2, x: 9.8, y: 7.7, vx: -0.2, vy: -0.1, a: 12 }, ], }

这里 x、y、速度、角度都是定点小数，传之前做个toFixed(2)转字符串再拼接，比传浮点数 JSON 省大约一半字节。实测 4 人在线时，每秒 30 次的同步流量在每条消息 200 字节以内，相当轻。

断线重连这块，我一开始没做，结果内测时房主一关浏览器整个房间就散了。后来加了两个保护：一是iceConnectionState变成disconnected后先等待 5 秒，不立即判死亡，因为部分移动网络切换会导致临时断流；二是发出一个“主机迁移”消息，当原房主掉线超过 10 秒时，自动指定加入者中延迟最低的玩家成为新房主，并把自己的状态快照发给它作为权威状态基准。这个机制实现不算复杂，但对局稳定性提升非常明显。

5. 节奏类小游戏与 P2P 实时对抗的性能实操

5.1 mikutap 式音游的音频调度陷阱

mikutap 这类游戏最打动人的地方是“音画一体”——每一次点击都触发相应的音色和粒子爆炸，节奏感极强。它的核心问题在于音频延迟。如果你直接在keydown事件里source.start()，浏览器音频线程和渲染线程之间的调度误差会导致某些音色明显滞后，节奏一快就露馅。

正确做法是提前调度。我参考了很多音游引擎的做法，实现了一个 lookahead 调度器：每 25ms 检查一次当前时间和待播放队列，把未来 100ms 内需要播放的音符全部排进AudioContext的调度时间轴。

// engine/audio.js 片段 const lookahead = 0.1; // 提前100ms调度 const timerInterval = 0.025; function schedulerTick() { const now = audioContext.currentTime; while (nextNoteTime < now + lookahead) { scheduleNote(nextNoteTime); nextNoteTime += noteSpacing; } } setInterval(schedulerTick, timerInterval * 1000);

这样键盘按下到声音实际播出的延时被压缩到 10ms 以内，人耳几乎察觉不到。再加上粒子动画也按nextNoteTime的时间戳来触发，而不是按keydown触发，音画同步的自然感就出来了。

在 P2P 联机模式下，音频调度还有一个额外问题：对端看到的时刻和你不一致。解决方式是在联机协议里带上“逻辑时间戳”，播放方用AudioContext.currentTime减去逻辑时间戳算出延时差，再对本地音符补偿。实测下来这个方案让两个玩家的节奏感知误差控制在 50ms 内，足够应付大部分派对玩法。

5.2 帧与延迟的控制指标

小游戏联机最怕的不是帧率低，而是“手感不一致”。我在 OmniGame 里定义了三个核心指标：本地帧率（确保 60fps）、网络 RTT（通过 PING/PONG 持续测量）、以及逻辑时间偏差（客户端与房主状态同步的时间差）。

延迟补偿的逻辑不复杂：每个客户端在本地渲染时，用“本地渲染时间 - 延迟”作为采样点，向房主发送输入。这样相当于客户端提前把自己的操作发给房主，房主按“当前时间 + 平均延迟”来执行，能抵消掉一半以上的网络延迟。我实测在跨省 80ms 延迟的情况下，这套补偿让操作手感接近 30ms 延迟下的表现。

如果 RTT 超过 150ms，我会在游戏界面上显示一个网络质量提示，不再强行补偿，因为过度补偿反而会造成回滚式抖动。

5.3 移动端与低端机的优化清单

网页小游戏最容易被忽略的战场其实是手机。我整理了一份在自己项目里每一条都验证过的优化清单：

• Canvas 2D 的粒子数量控制在 300 以内，超过就复用旧粒子而不是新建对象。
• 避免每帧创建对象和字符串拼接，能缓存的坐标计算全部缓存。
• 关闭高分屏的强制 DPR 缩放，用canvas.width = clientWidth * Math.min(devicePixelRatio, 2)限制渲染分辨率。
• 音频解码在资源加载阶段完成，不要在游戏运行时decodeAudioData。
• 移动端的touchstart和click延迟不同，统一监听pointerdown，并设置touch-action: none防止双击放大。

低端机上最明显的提升来自限制 DPR。一台中端安卓机把渲染分辨率从 3x 降到 2x，Canvas 绘制耗时能减少一半以上，画面观感几乎无差别。

5.4 常用浏览器兼容性表格

在联机能力上，各浏览器的支持程度还是有些区别的。我把实测过的表现整理成表：

开发时我建议以 Chrome 为主基准，先在桌面完成全部调试，再真机测一套 iOS Safari 和 Android Chrome。移动端 WebRTC 偶发连接失败，大多数情况是系统 WebView 权限或后台挂起策略导致，不是代码问题。

6. 零依赖工程的发布链路与下一步

6.1 没有打包器的压缩与单文件发布

开发时我们用 ES Modules，发布前需要把代码合并成单个 JS 文件。这一步我坚持不用打包器，而是用 Python 写了一个 80 行的小脚本：读取入口main.js，遇到import语句就用对应文件内容替换，递归处理，最后输出一个game.js。

合并后的文件体积通常在 30-80KB，用 gzip 压缩后更小。由于没有第三方依赖，完全不用考虑 tree-shaking 和 source map，脚本的输出就是最终产物。配上index.html后，整个游戏就是一个静态文件夹，扔到任何 Nginx、GitHub Pages、对象存储 CDN 上都能跑。发布步骤缩短成两条命令：

python3 bundle.py src/main.js dist/game.js gzip -9 -k dist/game.js

6.2 调试与版本维护

没有打包器，调试反而更直观：浏览器直接加载源码，断点打在原始模块文件里，性能和网络面板看到的就是真实代码路径。开发时我会保持src/目录结构不变，发布时才合并。

版本维护上，我用文件名加参数的方式处理缓存：game.js?v=20250101。每次发版改一下参数，浏览器就会拉取新文件，不用折腾服务端缓存头。另外建议代码里打一个window.__OMNI_VERSION__常量，线上出问题时方便立刻定位是用哪个版本。

6.3 可以继续延伸的技术方向

OmniGame 目前只用到了一部分浏览器原生能力。我自己列了一个后续待做的清单：

• WebTransport：替代 WebSocket 信令的低延迟通道，数据可以把 HTMX 客户端与服务器通信体验提升一个等级。
• SharedArrayBuffer + Web Worker：把游戏逻辑放进 Worker 里跑，避免主线程被渲染拖累，也为多人状态计算留出空间。
• WebCodecs：需要更高画面表现力时，用它做视频流的低延迟传输，比走 WebRTC 媒体通道更可控。
• 多人房间容量扩展：目前 4-8 人规模已经验证稳定，如果想做到 16 人以上，需要考虑 relay 拓扑和消息聚合，那是另一个值得单独展开的话题。

这些方向都在“零依赖 + 原生 API”的范围内，可以继续沿着这条路线往下走。

最后说点个人体会。零依赖真正改变我的不是技术选型，而是写代码的心态——当代码库里每一行都是自己写的逻辑时，你会在动笔之前多问几遍“这里真的需要这么复杂吗”。这种约束对个人开发者和小团队非常友好，它逼着你在早期就做减法，而不是用框架的复杂度掩盖设计上的妥协。

如果你也想试试这条路，我的建议是不要一上来就做联机，先做一个零依赖的单机小游戏，跑通循环、音频、资源加载这一整套链路，然后再用 OmniGame 里的信令和 DataChannel 方案把对局链接起来。第一个版本慢一点没关系，跑通之后再迭代，你会发现在这个体系里，每一个新能力都是建立在完全受你控制的代码之上的。这种掌控感，才是“重新定义工程上限”这句话真正值钱的地方。