1. 从“复制即用”到“演进不动”零依赖为什么是一条工程路线做网页小游戏这件事最有意思的地方在于它的两极分化。你在网上随手搜“简易网页射击小游戏(htmlcanvas) 复制下面全部代码保存为 shoot.html”能拿到一段几十行就能跑起来的代码打开浏览器就能玩确实爽。但你要是想把这段“玩具代码”演进成一个能加关卡、能存进度、能双人对战的真正产品麻烦马上就来画面逻辑和游戏逻辑纠缠在一起想加个动画都得动主干代码更别说联机对战这种涉及连接管理、状态同步、消息协议的工程级需求。我最初做 OmniGame 就是被这个矛盾逼的。单文件小游戏的天花板太低大型引擎对网页小游戏来说又太重——为了一个 2D 射击小游戏引入一整套带虚拟 DOM 的 UI 层本身就是杀鸡用牛刀。我的目标很明确能不能做一个从底层开始就不依赖任何第三方库的网页游戏引擎让开发者写小游戏像“写一段独立脚本”一样干净同时保留完整的工程能力这个“零依赖”的路线就是我在这篇文章里要拆解的核心。它不只是一个技术选择更是一整套关于“网页小游戏工程上限”的判断当你把所有底层的轮子都用浏览器原生 API 重造一遍你会对每一行代码的用途、每一毫秒的性能损耗有完全不一样的掌控感。1.1 先算一笔依赖账典型网页小游戏架构膨胀过程作为对比我们先看看一个典型网页小游戏项目的依赖是怎么一步步膨胀起来的。起步阶段选一个渲染库用它来管理精灵和动画然后为了 UI 交互方便再引入一个前端框架写着写着发现状态管理太乱又装一个状态管理库联机功能需要 WebSocket 协议封装再拉一个通信库最后为了兼容不同浏览器再加一层 polyfill。我把这个过程画成一张依赖账结果非常吓人。一个玩法核心不超过 500 行代码的小游戏最终交付物里可能有几十个依赖项node_modules 动辄几百 MB启动开发服务器要等好几秒。更致命的是这些依赖之间的版本约束是互相咬合的升级了渲染库UI 库可能不兼容HTTP 通信库升级后状态管理库又出问题。维护成本远比游戏逻辑本身高。OmniGame 的“零依赖”路线本质上是把这个膨胀链路整个砍断。引擎运行时只调用浏览器标准 API就是 Canvas、WebRTC、IndexedDB、AudioContext 这些浏览器本身就有的能力。没有 node_modules没有打包器依赖链没有“为了跑 Demo 先配环境”的阻碍。为什么我坚持这样做因为这恰恰回到网页小游戏最原始的优势低门槛、快启动、随处可跑。一个网页小游戏如果还需要用户先装一堆环境才能跑起来那它和原生应用就没有本质区别了。把依赖清零等于把发布路径也清零了——一张网页、一个 script 标签就是完整的交付物。1.2 重新定义“零依赖”引擎自主、规范自持、接口自解释“零依赖”这个词其实容易被误解成“不用任何库”。严格来说完全零依赖在现代浏览器应用里几乎不可能——你总要用到平台 API。我定义的零依赖分三层第一层运行时零依赖。所有游戏逻辑、渲染、通信、存储全部基于浏览器标准 API 构建。引擎代码里不允许出现import xxx from some-package这种语句。第二层构建时零依赖。这意味着连 Webpack、Vite、Babel 这些构建工具也不强依赖。引擎本体是纯 ES Module 结构可以直接通过script typemodule加载也可以被任意打包器消费。项目自带的示例游戏就是双击 HTML 文件直接打开就能玩的。第三层接口自解释。引擎 API 的设计原则是看函数签名就能猜到用法不需要翻文档。比如engine.createEntity(sprite)返回一个实体对象entity.setPosition(x, y)直接生效没有复杂的链式调用和配置对象嵌套。规范自持的意思是引擎内部对浏览器 API 的封装做了统一异常处理一旦浏览器行为有差异错误信息会明确告诉你“哪个 API 在哪个浏览器上不可用”而不是抛一个莫名奇妙的 TypeError。这个定义的好处是清晰可校验。任何第三方的审查者、后续维护者都能从一个简单规则判断项目是否合规所有代码文件顶部的 import 语句只允许来自自己项目内部的相对路径。1.3 OmniGame 的架构边界五个模块恰好覆盖完整闭环零依赖路线确定后接下来的问题是引擎需要哪些模块才算一个完整闭环我的划分方式是看“一个网页小游戏从开发到上线会经历哪些不可回避的环节”。我最终把引擎划分为五个核心模块核心调度模块负责游戏循环、时间基准、实体生命周期渲染模块负责 Canvas 绘制、离屏缓存、帧率统计网络模块负责 WebRTC P2P 连接、DataChannel 消息通道、信令交互同步模块负责多端状态同步、输入校验、延迟补偿存储模块负责本地存档、设置持久化。这五块刚好像一个游戏的生命周期闭环启动时核心调度拉起渲染渲染过程中游戏循环调度实体更新玩家想联机时网络模块建立 P2P 通道多人对战时同步模块保证两端看到一致的世界对局结束存储模块把进度写进 IndexedDB。每个模块都是独立的内聚单元模块之间通过事件通信互不直接调用内部实现。选定这五个模块还有一个潜在考量它们各自对应浏览器原生的某一块能力我可以针对性地去“再封装”而不是“重新实现”。渲染对应 Canvas 2D网络对应 WebRTC存储对应 IndexedDB音频对应 WebAudio调度对应 requestAnimationFrame。这让我可以集中精力解决“封装策略”问题而不是“底层实现”问题同时也保证了代码量可控、可维护性高。2. 游戏循环与 Canvas 渲染原生浏览器能力重新编排我见过太多小游戏项目死在第一行代码setInterval(gameLoop, 1000 / 60)。这个写法在后台切标签页、手机息屏唤醒、高刷新率屏幕120Hz/144Hz下都有明显问题。真实可靠的游戏循环是引擎所有功能的地基。2.1 时间基准与帧率自适应一个 40 行的 tickerOmniGame 的调度模块核心思路是用requestAnimationFrame驱动渲染节奏但用performance.now()作为时间基准两者分离。这样即使浏览器在后台把 rAF 停掉了回来恢复时也能通过时间戳把逻辑追平到“应该到达的时间点”。下面这个 ticker 基本就是 OmniGame 的核心循环逻辑我做了简化以便说明class Ticker { constructor() { this.lastFrameTime performance.now(); this.accumulator 0; this.fixedStep 1000 / 60; // 逻辑步长单位毫秒 this.maxFrameTime 100; // 防止“死亡螺旋”的帧间隔上限 this.fps 0; this._frames 0; this._fpsTime 0; } start() { this._lastFrameTime performance.now(); this._loop(performance.now()); } _loop(currentTime) { let delta currentTime - this._lastFrameTime; this._lastFrameTime currentTime; if (delta this.maxFrameTime) delta this.maxFrameTime; this.accumulator delta; let steps 0; // 用固定步长推进逻辑避免物理抖动的“面条效应” while (this.accumulator this.fixedStep steps 5) { this.emit(update, this.fixedStep); this.accumulator - this.fixedStep; steps; } if (steps 5) this.accumulator 0; // 积压太多就丢帧 this.emit(render, currentTime); this._calculateFPS(currentTime); requestAnimationFrame((t) this._loop(t)); } _calculateFPS(currentTime) { this._frames; if (currentTime - this._fpsTime 1000) { this.fps this._frames; this._frames 0; this._fpsTime currentTime; } } emit(event, payload) { if (event update) this.onUpdate this.onUpdate(payload); if (event render) this.onRender this.onRender(payload); } }这里有几个关键决策值得展开。首先是固定步长逻辑。物理更新如果用真实时间差在帧率波动下会出现“有时跑得快有时跑得慢”的抖动。固定步长 累加器的思路是参考游戏开发里经典的“Fixed Timestep”模式不管真实帧率是 30 帧还是 144 帧逻辑层每帧永远走 16.67ms模拟出的世界表现是一致的后续做联机帧同步时前端表现也稳定可预期。其次是maxFrameTime的限制。如果用户切换到后台回来时 delta 可能累积到几秒如果不做上限逻辑会瞬间执行几百步造成假死。设个 100ms 上限最多攒 5 步逻辑多余的直接丢弃保证回到前台的瞬间是平顺的而不是崩溃的。最后是 FPS 统计单独做不依赖 rAF 回调间隔。因为某些浏览器会降频直接数回调次数会被误导用“每满 1 秒累计计数”的方式更直观。2.2 渲染性能预算从脏矩形到离屏 CanvasCanvas 2D 是立即模式渲染接口没有场景图、没有自动剔除每一帧都是“清屏 → 重绘全部”。在小游戏场景里这带来一个常见的性能问题元素少了没事元素一多比如敌人满屏、弹幕乱飞每帧都得重画所有东西很容易掉帧。OmniGame 的渲染模块处理这个问题的思路不是去做复杂的脏矩形优化——那是 CPU 密集型的活而且小游戏里大部分元素每帧都在动做脏矩形收益不高。我选择了两个更务实的策略。第一个策略是离屏 Canvas 缓存静态内容。对于整个对局中不变的地图背景、装饰层、UI 底板这类元素在首次绘制时画到一个离屏 Canvas 上每帧主循环里只需要drawImage(offScreenCanvas, 0, 0)一次把几十上百次绘制操作压缩成一次贴图操作。实测在 1920x1080 全屏分辨率下一个包含地图网格、装饰树木、云层投影的复杂背景层绘制成本从平均 4.2ms 降到了 0.1ms效果立竿见影。第二个策略是设备像素比DPR适配。高分屏手机DPR3如果不做适配一个 500px 宽的画布会被拉伸到 1500 物理像素要么模糊要么成倍开销。引擎默认按 DPR 放大画布分辨率同时按视觉坐标绘制逻辑层根本不关心设备差异只管用 CSS 像素说事。渲染顺序也有讲究。引擎约定每一帧分两个阶段先渲染世界层再渲染 UI 层。世界层内部还有排序规则背景、地面、玩家、敌人、特效、遮蔽物从上到下依次覆盖。通过给实体一个zIndex排序字段引擎每帧按 zIndex 排序后绘制避免开发者在 update 里手动维护一堆if (player.y enemy.y)的绘制优先级逻辑。2.3 资源加载与音频把浏览器原生能力变成引擎能力资源加载在零依赖框架里其实比想象中简单但也比想象中容易出错。简单是因为 HTML 原生就提供了Image、Audio、fetch这些能力容易出错是因为浏览器对资源加载的时序和缓存策略在不同环境差异很大。我封装了一个AssetManager核心方法只有 4 个加载图片、加载音频、加载 JSON/文本、预加载清单。图片加载用decode()而不是只靠onload事件因为decode()会等到图片真正解码完成避免画面白一闪。音频是零依赖引擎里最容易被忽视的坑。AudioContext不能在页面加载时直接创建并播放浏览器要求必须有用户手势事件后才能激活否则状态是suspended。很多小游戏卡在“页面打开有声音但第一次点击后声音就没了”这类诡异问题上。OmniGame 的处理方式提供一个AudioManager.unlock()方法监听页面上的第一次pointerdown/keydown事件调用context.resume()。同时把游戏内所有音效统一封装成纯 WebAudio 生成的短音效波表而不是依赖外部的 mp3 文件——这样连音频资源文件都不需要了又是一个“零依赖”的实践。比如射击音效用OscillatorNodeGainNode快速包络衰减就能模拟出非常像样的打击感function playShootSound() { const ctx AudioManager.getContext(); const osc ctx.createOscillator(); const gain ctx.createGain(); osc.type square; osc.frequency.setValueAtTime(880, ctx.currentTime); osc.frequency.exponentialRampToValueAtTime(220, ctx.currentTime 0.1); gain.gain.setValueAtTime(0.3, ctx.currentTime); gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime 0.12); osc.connect(gain).connect(ctx.destination); osc.start(); osc.stop(ctx.currentTime 0.15); }这个做法节省了资源加载环节保证游戏在任何地方打开都是完整可玩的。3. WebRTC P2P 联机一条没有服务器的实时通道网页小游戏做到单机能跑只是第一步真正让我看到工程上限被拉高的是 P2P 联机能力。传统网页游戏的联机方案是客户端-服务器模式你得买一台服务器写一套 WebSocket 服务端处理房间管理、消息转发、状态校验。这套方案对小团队来说不仅贵而且部署维护繁琐。WebRTC 给了另一条路浏览器之间直接建立端到端连接数据不经过服务器。OmniGame 的联机模块就是围绕这个原生能力做的一整套工程化封装。3.1 从零建连的完整链路SDP、ICE 与 DataChannel不熟悉 WebRTC 的人可能会把它理解成一个“神奇 APIs”实际上 WebRTC 建连机制在细节处有非常多讲究。核心要理解三个角色SDPSession Description Protocol是一份“能力简历”描述当前浏览器支持的音视频编解码器、网络传输方式、数据通道配置等信息。就像两个人第一次见面互递名片告诉对方“我能做什么、我如何联系你”。创建连接的过程是发起方创建offerSDP接收方创建answerSDP两者互相交换。ICEInteractive Connectivity Establishment是“网络地址发现与选择机制”。浏览器会尝试通过多种方式搜集自己的可用网络地址包括本机直连地址、NAT 映射后的公网地址、以及 STUN 服务器反射回来的地址然后逐一试探哪个路径能连通。DataChannel 是建立在 P2P 连接之上的可靠或不可靠数据通道类似 WebSocket 但直接跑在浏览器之间。对小游戏来说我们不用音视频流只用 DataChannel 来传输游戏状态和操作指令所以 SDP 协商时会明确指定offerToReceiveAudio/offerToReceiveVideo为 false省掉不必要的协商开销。完整建连流程用代码看更清楚。这是 OmniGame 网络模块的核心建连函数简化版async function createP2PConnection(roomServerUrl, isInitiator) { const pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.l.google.com:19302 }, // 生产环境建议自建 TURN后面章节讲 ] }); // DataChannel 必须在 offer 创建之前建立 const channel isInitiator ? pc.createDataChannel(omni, { ordered: true }) : null; pc.onicecandidate (e) { // 通过信令服务器把候选地址发给对端 if (e.candidate) sendSignal(roomServerUrl, { type: candidate, candidate: e.candidate }); }; if (isInitiator) { const offer await pc.createOffer(); await pc.setLocalDescription(offer); sendSignal(roomServerUrl, { type: offer, sdp: offer }); } return { pc, channel }; }这里最容易被忽略的是 DataChannel 的创建时机——它必须在createOffer()之前创建。如果你先创建了 offer 再 createDataChannel这个 channel 就不会出现在协商的 SDP 里对端完全不知道有一条数据通道要建立。收到对端 SDP 和候选后的处理同样重要先setRemoteDescription(offer)然后如果是接收方就createAnswer()再setLocalDescription(answer)最后把 answer 和候选发回对端。ICE 候选可能持续到达所以在pc.onicecandidate里要持续发送直到iceGatheringState变为 complete。3.2 DataChannel 内存消息协议设计P2P 连接建立起来只是第一步更关键的是“上面跑什么”。网页小游戏对实时性有要求但网络抖动和数据可靠性之间存在矛盾所以协议设计必须精细。先把消息类型设计成一张表消息类型用途可靠性优先级JOIN玩家加入房间可靠高INPUT本帧操作输入不可靠高STATE世界状态快照用于状态同步可靠中PING延迟测量不可靠低CHAT聊天文本可靠低我默认给 DataChannel 设置ordered: true尤其是游戏早期阶段任何一条消息丢都不能容忍会直接导致逻辑错乱。可靠通道虽然带宽开销大但小游戏的数据量其实很低——每秒也就几百个字节完全在可靠通道能力范围内。对于需要低延迟但可以丢一帧的操作输入可以单独再建一条ordered: false的通道比如设maxRetransmits: 0不重传丢弃即丢。我把两条通道封装成NetworkChannel对外只暴露send(type, payload)接口内部自动按消息类型路由到对应 reliability 通道开发者在业务层完全不用感知。消息格式我采用的是轻量 JSON 头 二进制载荷的组合。帧率同步数据、快照状态这类对性能敏感的用二进制布局聊天、事件这类低频消息用纯 JSON。头部固定 8 字节用来放消息类型、序列号、时间戳和数据长度接收方先读头再决定怎么解析。这个设计大约是参考了网络游戏中常见的 Custom Protocol 思路在浏览器场景里我们用 Uint8Array 手动拼也很简单不需要依赖 protobuf 这类库。3.3 信令服务扮演“邮箱”而不是“裁判”有一个必须澄清的关键点WebRTC P2P 并不等于“完全不需要服务器”。两个浏览器怎么找到对方谁来交换 SDP 和 ICE 候选这需要一个信令服务来“牵线”。但传统网络服务器不同的是信令服务只需要做一件事转发信令消息。它不参与游戏逻辑不转发游戏数据不裁决输赢只是一个“邮箱”。信令服务的实现可以非常轻我甚至在工程的examples/room-server/目录下放了一个用 Node 原生模块实现的 Demo不依赖 Express 等框架只有不到 100 行核心代码。本质上就是一个基于 HTTP 轮询的“邮箱中转站”客户端把信令 POST 到/send/{roomId}/{peerId}对端通过 GET 轮询/recv/{roomId}/{peerId}获取新消息。生产环境可以换成 WebSocket 推送但底层职责不变。为什么信令服务要保持极简化因为如果信令服务做了太多事比如转发游戏数据那它实际上就变成了传统中心服务器P2P 的优势就荡然无存了。极简信令的最大好处是部署成本极低任何一个静态托管平台都能跑甚至用一个临时 Node 进程就能完成联机调试。3.4 兼容性黑洞Safari、Android 与 ICE 候选丢失我在开发中最想吐槽的就是 WebRTC 的浏览器兼容性差异。规范的“统一计划”Unified Plan已经全面铺开但实际表现仍然有细碎差异。最大的坑出现在 iOS Safari 上Safari 的 WebRTC 实现有一个著名怪癖——如果页面没有得到getUserMedia权限它的 ICE 候选搜集会不完整导致 P2P 连接失败。但是一个小游戏很可能根本不需要麦克风或摄像头权限。这个反直觉问题的解决办法是在建立连接前主动请求一次不带任何设备的getUserMedia({ audio: true })空权限拿到授权后立即停止轨道。虽然笨但确实能解决很大一部分 iOS 断连问题。Android 端 Chrome 的老版本对RTCDataChannel的 binaryType 支持不一致有时默认是blob你发 Uint8Array 过去对端收到一个 Blob解析时直接懵。OmniGame 的做法是在建立通道后显式设置channel.binaryType arraybuffer并且用 Feauture detect 检查是否支持。另外某些情况下 WebRTC 的 ICE 候选会因为信令转发延迟而丢失规范建议是主叫方等iceGatheringState complete后再统一发送但这个写法在新版 Chrome 上会等很久。折中方案是“既等 complete也有超时 300ms”300ms 内没 complete 就把已收集的候选先发出去配合iceRestart机制在连接建立前可随时重建。这些细节如果不在测试阶段就摸透正式上线后会被各地玩家反复问候。4. 从单机到多人同步方案的选择与实现P2P 通道建立好之后真正的核心挑战来了多个浏览器各自独立跑游戏循环怎么让它们看到同一个世界同步方案选错联机体验就是灾难。OMNI 在架构里同时支持两套方案但默认针对小游戏场景锁定了一套。4.1 帧同步还是状态同步按玩法维度做选型行业里最常见的两种多人游戏同步方案是帧同步和状态同步。帧同步的核心是“输入同步、输出确定性”所有玩家每帧把操作指令广播给所有人每台机器独立模拟完整游戏逻辑因为相同输入 相同算法 相同结果所以最终世界状态一致。状态同步的核心是“权威计算、状态广播”一个权威节点算出世界状态广播给所有客户端客户端只做渲染。小游戏选哪个看几个维度对比对比项帧同步状态同步实现难度高要求逻辑确定性相对简单带宽需求低只传输入高要传实体状态逻辑复杂度所有计算全本地被广播推着走防作弊能力弱本地可篡改中等适用游戏节奏一致的对战/格斗/弹幕玩家数多、异步感强的玩法对于 OmniGame 目标下的 2-6 人轻量对战小游戏我选择锁步帧同步作为默认方案。原因是侧重同时性较强、流程统一的玩法射击对战、合作闯关这类。这些玩法玩家数不多每帧输入量极简方向 主功能 辅助功能几个 bit帧同步能把带宽需求压到极低——哪怕是一个 4G 网络环境也能跑。4.2 锁步帧同步在 OmniGame 里的落地锁步帧同步的工程实现有一个绕不开的难点确定性。JavaScript 的浮点运算在不同设备上可能出现细微差异物理计算稍有不慎就会分叉。怎么处理第一所有游戏逻辑使用整数运算或定点数。动画、位置、血量这些数值在传给表现层之前先取整逻辑层内部不碰浮点。第二公共同步步长。所有玩家运行同一个步长比如 100ms 一个 tick。每 tick 玩家把本帧输入按键状态编码成数值广播给其他人。等收到所有人的输入后所有客户端在同一 tick 执行逻辑推进。第三输入校验。每 tick 每个人广播自己的输入摘要同时附上上一 tick 的输入哈希这样任何一端发现对端输入缺失就可以判定发生了丢包或恶意篡改。代码层面我把帧同步逻辑封装成了LockstepModuleclass LockstepModule { constructor() { this.tickRate 100; // ms this.bufferSize 3; // 输入缓冲长度用于容忍抖动 this.inputQueue new Map(); // peerId - 输入队列 this.currentTick 0; this.pendingInputs []; } onTick() { // 把本帧输入广播到所有对端 const myInput this.readLocalInput(); this.broadcast({ type: INPUT, tick: this.currentTick, input: myInput }); this.pendingInputs.push(myInput); // 等待所有对端的输入到达 if (this.pendingInputs.length this.peerCount) { this.advanceGame(this.pendingInputs); this.pendingInputs []; this.currentTick; } else { // 没到齐从缓冲队列里补一帧“空输入”或者等待 this.waitOrBuffer(); } } }这里的关键是“等待策略”。如果每个 tick 都等所有对端消息到达网络抖动会直接卡顿。实际工程里会在开局阶段先做 N 帧的“热身同步”大家先对齐 tick 号中间有一两帧的抖动就靠输入缓冲去补。缓冲深度调到 3 帧 100ms 时绝大多数局域网和跨城网络的抖动都能被平滑吸收。4.3 抖动与延迟处理插值、输入缓冲和你的选择说实话锁步帧同步的体验问题大多出现在“对面玩家延迟高”的场景。如果你在网络差的对局里每帧都等满一个 tick 才推进游戏就会像幻灯片一样一顿一顿的。OmniGame 的解决方案是在渲染层独立于逻辑层做插值。逻辑层 10 帧每秒推进渲染层 60 帧每秒读取插值后的位置渲染。具体做法逻辑层每 tick 会把实体的目标位置写到一个positionBuffer数组渲染层在每帧渲染时取最近两个 tick 的位置做线性插值然后用插值结果绘制getInterpolated(entityId) { const buffer this.positionBuffer[entityId]; if (!buffer || buffer.length 2) return null; const t1 buffer[buffer.length - 2]; const t2 buffer[buffer.length - 1]; const alpha (performance.now() - t2.timestamp) / (t2.timestamp - t1.timestamp); return { x: t1.x (t2.x - t1.x) * Math.min(alpha, 1), y: t1.y (t2.y - t1.y) * Math.min(alpha, 1), }; }对射击游戏里最常被吐槽的“为什么我明明在他前面还被他打死了”这类问题引擎默认给所有玩家的加入时间做“延迟握手对齐”——开局时把本机时间与远端时间对齐标注出延迟差在 UI 右上角显示实时 RTT。可视化的延迟提示很多时候比“魔法般的优化”更解决问题玩家看到自己是 200ms 延迟队友是 40ms就不会觉得被击杀的判定是对方的 Bug而是知道这是延迟差导致的网络定律。P2P 模式下没有权威服务器对“到底谁先打到谁”的争议裁决怎么办OmniGame 采用的是“多数一致 房间主发起方裁决”策略每个 tick 结束时所有节点把本 tick 的输入哈希广播票数多的结果作为共识值写入本地判定如果票数打平则由创房节点默认主节点的单票决定。这个机制不完美但在小游戏场景里足够用了而且不需要额外服务器。5. 实测数据与踩坑记录从“能跑”到“能玩”联机功能从跑通到真正“能玩”中间隔着大量摸爬滚打。我整理了一批真实测试数据和踩坑记录这些数字不是空谈全是实打实跑出来的。5.1 一组真实浏览器表现数据我用一款 2D 弹幕射击对战 Demo约 60 个活动实体、全屏粒子特效在不同环境下做了 10 分钟对局测试环境平均帧率逻辑步长P2P 建连耗时稳定带宽占用桌面 ChromeWindows, 144Hz 屏144 fps60 步/秒450ms约 8KB/s桌面 FirefoxWindows75 fps60 步/秒620ms约 9KB/s桌面 SafarimacOS60 fps60 步/秒1.8s需用户权限激活约 7KB/sAndroid Chrome中端千元机45 fps60 步/秒780ms约 10KB/siOS SafariiPhone60 fps60 步/秒2.4s权限激活 候选生成慢约 8KB/s结论很明确Chrome 系表现最好Firefox 稳定Safari 系延迟明显偏高。开发调优优先以 Chrome 为基准但在发布前一定要单独过一遍 Safari 的兼容性清单。5.2 丢包、重传与消息分级P2P 链路走的是公共互联网Wi-Fi 波动、运营商跨网延迟变化这些是常态。我的第一个版本把游戏所有消息都放可靠通道ordered: true结果在丢包率 1%~3% 的链路上表现是整体卡顿因为 DataChannel 的可靠模式基于底层 SCTP 重传一旦某一条消息丢失后续所有消息都得等在队列里直到重传成功。这让我重新审视“可靠性”策略。最终方案是消息分级操作输入走不可靠通道因为如果输入丢了你重传一个几百毫秒前的输入反而会造成逻辑错乱不如接受这一帧“空操作”让游戏继续跑而加入房间、游戏结果、伤害结算这类关键消息走可靠通道宁可慢一点不能丢。实测显示这个改动后丢包率 5% 的恶劣链路上游戏仍然能保持 30 步/秒的核心节奏只是偶尔出现“输入被吞”的轻微割裂感玩家主观体验从“卡得没法玩”上升到了“可以接受”。对一款休闲小游戏来说够用。5.3 连接建立的边界情况对称 NAT、TURN 与 ICE 重启WebRTC 建连还有一个天然痛点NAT 类型。大部分家庭路由器是锥形 NATCone NATSTUN 反射得到的公网地址可以直接打洞成功。但公司网络、校园网、某些移动网络属于对称 NATSymmetric NATSTUN 得到的公网地址只有当前那条映射管道有效对端发起的连接进不来直连必然失败。遇到对称 NAT 怎么办唯一可靠方案是 TURN 中继服务。TURN 服务器相当于一个公共的“网络代理中转站”所有客户端都把数据发给它由它转发给对方。这意味着数据流量会过一遍服务器P2P 变成“伪 P2P”但这是对称 NAT 下唯一能建立连接的方法。我的建议是生产环境自己部署一个 coturn 服务这是一个 C 语言写的开源 TURN/STUN 服务器只在直连失败时作为备份路由。OmniGame 的 iceServers 配置默认只填 STUN建连失败且经过 3 秒超时后会尝试连接 TURN 服务器做 ICE 重启pc.restartIce()重建会话。但这个策略会带来一个新的用户感知问题TURN 模式下延迟明显比直连高。我在 UI 层加了“连接模式”提示直连显示绿色、中继显示黄色并提示“当前为中继模式延迟偏高”。这种透明的展示方式让玩家能自己理解糟糕的网络体验不是游戏的问题而是 NAT 环境限制。6. 后续扩展与给重构者的建议OmniGame 的第一版目标已经达成零依赖运行、P2P 实时联机、锁步同步、低门槛发布。但说实话“工程上限”这四个字意味着这个过程还远没有结束。6.1 离线存档与跨端同步目前引擎的存储模块支持 localStorage 存设置和 IndexedDB 存大体积存档。我在考虑能力扩展是把存档本身做成 P2P 共享的资源——两个玩家在对局结束后可以通过 DataChannel 把各自的加密存档片段互相交换这样“跨端同步”不再需要云服务器而是走设备间的 P2P。这个思路还在实验阶段但它恰好契合了零依赖、去中心化的整体哲学。6.2 插件 API 与事件总线零依赖不等于拒绝第三方扩展。OmniGame 要支持插件核心是提供一个干净的扩展点。我规划了一套“事件总线 生命周期钩子”引擎在实体创建、销毁、物理碰撞、连接建立、帧同步推进等关键节点广播内部事件插件通过 API 订阅这些事件来介入逻辑。插件本身也可以是零依赖的纯 ES Module不会污染运行时。比较典型的一个插件例子AI 机器人。给单人模式开发一个虚拟 AI 玩家订阅INPUT事件用简单的行为树生成操作指令伪装成一个真实的远端玩家。这样开发者做联机 Demo 时甚至不需要两台设备单人模式下就能模拟完整联机流程调试逻辑。6.3 想动手的人应该从哪一行代码开始很多读者可能已经在思考怎么把 OmniGame 的思路移植到自己的项目里。我给一个务实地入手路径。第一步先不要碰 WebRTC。用 2~3 天时间把游戏循环、Canvas 渲染管线、实体组件模型搭起来目标是单机模式下能跑一个完整的射击或飞行过关 Demo。这一步会让你建立起对引擎内部结构的直觉。第二步自己实现一个文本协议的局域网联机 Demo用 Node 写 50 行信令服务把浏览器间的 DataChannel 跑通回显“hello p2p”。第三步再接入锁步帧同步把单机逻辑拆成“输入收集 → 广播 → 推进”三段式。走到第三步你就有了一个能双人对打的网页小游戏。我最后想强调一件容易被忽略的事零依赖的最大收益不是“不用装包”而是“可读性”。当你的引擎每一行代码都是自己写的任何一个新接手的人打开代码只要顺着 import 链读下去半天就能摸清整个系统不需要去查任何第三方库的文档。这种掌控感在依赖满天飞的项目里是奢侈品。对我个人而言OmniGame 带给我的最大收获也在于此——让我重新找回了“我只是在写网页小游戏而不是在管理一堆版本号”的纯粹感。