开工前先说几句实在话看到大鱼吃小鱼 web小游戏开源这个标题我第一反应是又一个经典玩法的小项目。但认真琢磨之后发现这类项目恰恰是前端学习路径上最值得动手写一遍的东西。它看起来简单却能把 Canvas 渲染、游戏循环、碰撞检测、对象管理、状态机这些前端游戏开发的核心知识点全部串起来而且玩法老少皆宜拿来练手、写博客、做作品集都很合适。这篇文章我基于自己重写和优化这类游戏的实践经验完整拆解从玩法设计到核心代码实现的全过程。不吹不黑我把每一个关键决策的原因、每一个参数的推导、每一个坑都写清楚你照着走一遍就能做出一个能玩、能看、能继续扩展的开源版本。无论你是刚学完 JavaScript 基础的前端新人还是想快速出一个小作品的老手这篇文章都值得花十分钟读完。1. 整体设计拆解为什么选这个玩法为什么这样搭1.1 玩法设计的核心逻辑大鱼吃小鱼本质上是一个不对称对抗游戏。玩家控制的鱼和 AI 鱼都遵循同一条规则比对方大就能吃吃了就长大长大就能吃更大的鱼。这个规则的妙处在于它天然形成了一条成长曲线和一个风险倒逼机制。前期你比大多数鱼大可以横行霸道这是爽感来源中期出现和你差不多大的鱼需要掂量到底打不打这是策略深度后期出现巨型鱼你反过来成了食物这是紧张感的来源所以游戏设计的第一件事不是写代码而是把这套成长曲线定好。决定曲线好坏的关键参数有两个鱼的尺寸分布和玩家初始大小。我实际测试下来的经验值是这样参数推荐初始值说明玩家初始半径12px不算最大也不算最小保留成长空间最小AI鱼半径5px太小了看不清碰撞体验差最大AI鱼半径60px超过屏幕宽度的1/10会显得笨重玩家与AI鱼的尺寸比阈值1.1倍只有大于对方1.1倍时才能吞噬避免相同大小也能吞的荒谬情况尺寸分布的随机算法要避免均匀分布正确做法是指数分布或分段加权随机。理由很简单如果均匀分布大小鱼数量差不多游戏中期会缺乏鱼群感。按照我的经验把50%的鱼控制在半径8~20px之间30%在20~35px15%在35~50px最后5%才是50px以上的大块头整体体验最舒服。1.2 技术选型为什么用原生 JavaScript Canvas而不是游戏引擎市面上有 Phaser、Cocos、Unity 这些引擎为什么我坚持用原生 JS Canvas第一个原因是学习价值。引擎帮你处理了渲染循环、碰撞物理、资源加载你写出来的代码只是调用 api 的脚本做完之后你对游戏到底怎么跑起来的还是一头雾水。用原生 Canvas你能亲手掌握requestAnimationFrame的节奏、认识渲染管线的开销、理解对象池的意义。这些知识是通用的以后你学任何引擎都能带着底层认知去理解它在做什么。第二个原因是开源友好。纯原生项目零依赖任何人拿到源码浏览器一开就能跑不需要安装编译工具链对想学习的人友好得多。这也是开源项目传播率高的一个关键因素——降低使用门槛。第三个原因是性能足够。这种 2D 休闲游戏的实体数量通常几百个以内Canvas 2D 的绘制能力完全不虚。我实测在低端移动设备上同时活跃鱼数量 200 时依然能保持 60FPS。所以根本不需要为了这种轻量游戏引入引擎那样重型的工具。1.3 代码结构前期规划决定后期维护体验很多人写小游戏习惯一个app.js从头写到尾刚开始没问题但一旦要加功能、修 bug就会发现自己都看不懂自己的代码。我推荐按照职责拆分哪怕这个项目很小。我的习惯结构是这样的大鱼吃小鱼/ ├── index.html # 页面骨架Canvas UI 层 ├── css/ │ └── style.css # 样式 └── js/ ├── config.js # 所有可调参数集中管理 ├── fish.js # 鱼实体类属性、行为 ├── spawner.js # 鱼群生成器生命周期管理 ├── input.js # 玩家输入鼠标、键盘、触控 ├── game.js # 游戏主逻辑循环、碰撞、状态管理 └── render.js # 渲染层绘制鱼、水波纹、特效这样拆的好处是转天你再打开这个项目或者别人拿到你的源码一看文件结构就知道去哪里改什么。参数集中在config.js里调平衡性的时候不需要翻遍代码找数字。2. 核心细节解析与实操要点2.1 鱼的行为让 AI 鱼看起来活起来AI 鱼的行为决定游戏是像一池子死鱼还是充满生机的水下世界。我的实现里给每条鱼分配了一个简单的状态机一共有三种状态闲逛、追击、逃跑。这三者之间根据周围局势切换。闲逛鱼以当前方向为基准每 200~500ms 随机偏转一个角度以恒定速度游动。为了让鱼群有聚拢感我在闲逛的目标方向上叠加了一个向场景中心偏移的权重避免鱼四散开来越游越远。追击当 AI 鱼发现某个目标比自己小且距离小于它的视线范围我设置为 150~250px它切换到追击状态。追击不是直勾勾地冲过去我会加一个 0.3 的偏航因子让鱼的转向有惯性看起来更像真实的鱼游动而不是导弹追踪。逃跑当 AI 鱼发现区域内存在半径大于自己 1.2 倍的鱼它会切换为逃跑状态。逃跑时速度提升 25%方向是远离威胁位置 当前方向的加权平均。这里的核心参数是视线范围和惯性转向因子。视线范围太大鱼会过于敏感全图大乱跑太小AI 又显得迟钝。惯性转向因子如果设成 1鱼就像机器人一样瞬间转向一旦设成 0.8 左右再配合一个随机抖动鱼游动的姿态就自然很多。另外要补充一个细节所有的 AI 决策不需要每帧都做。我在实测中发现每 150ms 做一次状态评估完全足够这样可以省掉大量无意义的判断计算。这是游戏优化中典型的时间换性能做法。2.2 碰撞检测距离判定是基础但要注意这些坑大鱼吃小鱼的碰撞检测是 2D 游戏最经典的圆形碰撞检测。核心原理一句话两个圆的中心距离小于两圆半径之和即判定为碰撞。用代码表示就是function isColliding(a, b) { const dx a.x - b.x; const dy a.y - b.y; const dist Math.sqrt(dx * dx dy * dy); return dist a.radius b.radius; }看起来简单但有两个坑你必须避开。第一个坑是每帧做全量两两检测的性能爆炸。如果有 200 条鱼全量配对就有 19900 次检测每次检测还要做开方运算这在低端设备上可能直接卡顿。我实际测试后发现200 条鱼全量检测时单帧耗时约 3~4ms看起来不严重但如果逻辑再复杂一点或者数量涨到 500 条帧时间可能飙升到 20ms 以上游戏就直接掉到 30FPS 以下。正解是贪心优化每帧只检测玩家鱼和 AI 鱼的碰撞以及 AI 鱼彼此之间的碰撞。AI 之间的碰撞检测只需要检测那些可能遇到的我用的是粗糙的分区检测——把整个屏幕分成若干个格子只检测相邻格子里的鱼。这个优化一上去性能立刻提升一个量级。第二个坑是边界碰撞的漏判。如果一条鱼移动很快可能上一帧还在左侧边界外下一帧已经穿过了右侧的一条鱼的位置两帧之间没有记录到相交。这就是隧穿效应。虽然在这个游戏里鱼的速度不至于快到穿鱼但在处理屏幕边缘时我发现如果不加位置钳制clamp鱼经常会游出边界然后卡在边缘半进半出看起来很难受。正确的做法是每一帧把鱼的位置限制在画布范围内并且确保当鱼的中心进入边界 1 倍半径距离时就触发转向而不是等它完全出去了再拉回来。2.3 成长体系尺寸增长要符合视觉直觉吃鱼长大的体验做得好不好直接决定这个游戏有没有手感。尺寸增长的核心设计原则是成长的视觉效果要明显但成长速度要递减。我采用的公式是player.radius Math.sqrt(player.radius * player.radius eatenFish.radius * eatenFish.radius * 0.3);这个公式来自面积叠加的概念。吃掉一条鱼的物理本质是把对方的体积加到自己身上面积二维体积是半径的平方。这里乘以 0.3 是一个能量损失系数如果完全 1:1 叠加玩家很快会变成巨无霸游戏就失去挑战了。我用 0.3 的原因是让玩家吃 2~3 条同尺寸的鱼才能明显提升一档保持持续的成长欲望。另外要注意的是速度补偿。按真实物理更大的鱼在水中移动速度会稍慢但在游戏里如果玩家越大越慢体验会非常糟糕成长期反而变迟钝。我做了个折中玩家速度与半径成弱负相关但不是线性而是对数关系。比如初始速度设为 3.6当半径到 40px 时速度降到 3.0 左右这个差异玩家能感觉到但不明显不会带来挫败感。2.4 Canvas 绘制鱼的视觉表现决定游戏质感谁能想到这个游戏的颜值关键不在鱼长什么样而在背景和动态效果。我最初一版做出来鱼只是一个圆形加上一个三角尾巴背景是纯白色玩起来感觉像在做数学题。后来我做了一个调整整个画面立刻有了灵魂。调整内容是背景绘制成从浅蓝到深蓝的渐变并且叠加一层缓缓漂移的光斑。具体实现是用createRadialGradient生成几个半透明的光斑每个十几秒做一次缓慢的圆周运动。这层背景大概增加了 1~2ms 的单帧绘制时间但视觉档次提升非常多。鱼本身的绘制我分了三个图层身体用ellipse绘制椭圆加一个的渐变色填充眼睛两个白色小圆加瞳孔圆瞳孔位置根据移动方向偏移这个细节特别能让鱼显得活着尾巴一个三角形根据游动方向做摆动摆动幅度与速度成正比这里有一个特别值得分享的经验眼睛的方向偏移要基于速度向量而不是位置变化。你在实现的时候如果直接用上次坐标减去这次坐标得到方向向量鱼静止时眼睛会抖动正确做法是记录鱼当前的速度向量并做平滑插值。代码大致是// 眼睛方向角的平滑处理 const targetAngle Math.atan2(velocity.y, velocity.x); currentEyeAngle (targetAngle - currentEyeAngle) * 0.2;这个 0.2 的插值因子让鱼转头时眼睛有个自然的跟随过渡不会摔角式瞬移。3. 实操过程与核心环节实现3.1 场景初始化与 Canvas 自适应Canvas 自适应是小游戏最容易忽略的大坑。很多人直接写死宽高拿不同尺寸的屏幕打开后不是变形就是显示不全。我的做法是让 Canvas 铺满整个视口并且根据devicePixelRatio做锐化处理。function initCanvas() { const canvas document.getElementById(gameCanvas); const ctx canvas.getContext(2d); const dpr window.devicePixelRatio || 1; canvas.width window.innerWidth * dpr; canvas.height window.innerHeight * dpr; canvas.style.width window.innerWidth px; canvas.style.height window.innerHeight px; ctx.scale(dpr, dpr); // 统一的逻辑坐标系之后所有绘制都按逻辑像素走 return { canvas, ctx, width: window.innerWidth, height: window.innerHeight }; }这里关键是ctx.scale(dpr, dpr)这一行处理之后你写的绘制代码永远按照 CSS 像素的尺寸工作高 DPI 屏幕上不会发虚。没有这一行的话iPhone 这种 3 倍屏上画出来的鱼会明显模糊。记得监听resize事件重新初始化移动端旋转屏幕时不会出 bug。3.2 游戏主循环保持稳定帧率的根基主循环使用requestAnimationFrame这是所有现代浏览器游戏渲染的标准方案。我建议你从一开始就把循环和物理更新分离而不是把逻辑全部塞进 rAF 回调里。let lastTime 0; const TICK_RATE 60; function gameLoop(timestamp) { const delta (timestamp - lastTime) / 1000; lastTime timestamp; // 固定步长逻辑更新 update(delta); // 渲染 render(); requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);上面这段代码有一个隐患就是delta如果过大比如浏览器标签页切回来会导致鱼一帧跳很远。我处理的方案是限制delta最大值为1/30秒超过就按1/30算这样切后台再回来游戏不会出现鱼瞬移半个屏幕的情况。3.3 鱼的生成器控制生态平衡生成器的作用是让场景中的鱼数量维持在目标区间。不能一次性生成所有鱼然后不管了因为鱼会被吃掉、会自己产生生态系统需要动态补充。我的实现思路是这样class Spawner { constructor(sceneWidth, sceneHeight) { this.targetCount 80; this.minCount 60; this.maxCount 120; this.fishList []; this.sceneWidth sceneWidth; this.sceneHeight sceneHeight; } update(delta) { // 每帧检查数量低于下限就补充 if (this.fishList.length this.minCount) { this.spawnFish(this.minCount - this.fishList.length); } // 超过上限就清除最远处的鱼通常是被边缘卡住或玩家没注意到的鱼 if (this.fishList.length this.maxCount) { this.fishList.splice(this.maxCount); } // 清理标记为已死亡的鱼 for (let i this.fishList.length - 1; i 0; i--) { if (this.fishList[i].dead) { this.fishList.splice(i, 1); } } } }鱼生成的位置必须考虑玩家的视线。我的做法是玩家周围 300px 范围内生成概率降低 30%避免频繁有鱼突然出现在脸上这个细节能显著减少莫名被吞的抱怨。生成鱼的时候还要随机决定尺寸但不能完全随机。我用了分段加权function randomFishRadius() { const r Math.random(); if (r 0.5) return 5 Math.random() * 15; // 小鱼 if (r 0.8) return 20 Math.random() * 15; // 中鱼 if (r 0.95) return 35 Math.random() * 15; // 大鱼 return 50 Math.random() * 40; // 巨型鱼 }注意巨型鱼的比例只有 5%但如果玩家已经长到足够大巨型鱼就是他的主要升级资源所以这个比例不能太低。3.4 玩家输入鼠标为主、键盘触控为辅鼠标控制是最直接的方式。鱼向鼠标位置游动但不用瞬移而是有最大速度的追击。这样玩家操作起来有一点手感重量比完全指针跟手更有游戏性。function updatePlayer(delta) { const angle Math.atan2(mouse.y - player.y, mouse.x - player.x); const speed player.speed; player.vx Math.cos(angle) * speed; player.vy Math.sin(angle) * speed; // 平滑移动 player.x player.vx * delta * 60; player.y player.vy * delta * 60; }键盘控制用的 WASD触控是拖拽控制方向。拖拽控制有个细节玩家手指按下的点作为方向基准手指向某个方向滑动鱼向同方向移动。不要做直接跟手到手指位置那会遮挡大面积屏幕而且手感非常飘。3.5 吞食判定与视觉反馈判定的触发条件有两个碰撞发生 尺寸比达标。尺寸比我是用半径比而不是面积比因为玩家直观感知是看起来谁大半径比更符合视觉直觉。function tryEat(player, fish) { if (player.radius fish.radius * 1.1) { playEatEffect(fish); player.radius Math.sqrt(player.radius * player.radius fish.radius * fish.radius * 0.3); fish.dead true; score Math.floor(fish.radius * fish.radius); } else if (fish.radius player.radius * 1.1) { gameOver(); } }注意这里打平的情况两者都吞噬不了时应该什么都不发生鱼擦肩而过不要死循环碰撞。吞食的视觉反馈是加分的关键。我实现了一个粒子特效系统鱼死亡时在该位置生成 6~10 个小泡粒子向四周散开并缓慢上浮然后消失。这套粒子特效的代码不超过 30 行但对玩家的击中感提升立竿见影。同时吞食时播放一个短促的咕噜气泡音效我用的方法是 Web Audio API 生成一段短暂的噪声function playEatSound() { const ctx new (window.AudioContext || window.webkitAudioContext)(); const oscillator ctx.createOscillator(); const gainNode ctx.createGain(); oscillator.connect(gainNode); gainNode.connect(ctx.destination); oscillator.frequency.setValueAtTime(400, ctx.currentTime); oscillator.frequency.exponentialRampToValueAtTime(700, ctx.currentTime 0.1); gainNode.gain.setValueAtTime(0.2, ctx.currentTime); gainNode.gain.exponentialRampToValueAtTime(0.01, ctx.currentTime 0.15); oscillator.start(ctx.currentTime); oscillator.stop(ctx.currentTime 0.15); }这个方法的好处是不需要任何音频素材文件代码就是音频开源项目用起来非常干净。4. 性能优化与渲染细节4.1 对象池避免 GC 卡顿的必修课游戏运行中最常见的性能杀手不是绘制本身而是垃圾回收GC导致的帧率波动。每次生成一条新鱼都需要new Fish()建对象每次鱼死亡又把它置为null让 V8 去回收内存。高频的创建销毁会让 GC 不定期触发玩家会偶尔感到一卡一卡。解决思路是对象池提前创建一批鱼对象不使用的放到池子里要用时取出不用时放回。class FishPool { constructor(size) { this.pool []; for (let i 0; i size; i) { this.pool.push(createFish()); } this.active []; } getFish(config) { const fish this.pool.pop() || createFish(); Object.assign(fish, config); fish.dead false; this.active.push(fish); return fish; } recycleFish(fish) { fish.dead true; this.pool.push(fish); const idx this.active.indexOf(fish); if (idx ! -1) this.active.splice(idx, 1); } }我实际测试下来引入对象池后200 条鱼持续运行的 GC 暂停时长从平均每 30 秒 50ms 降到了几乎为 0。这个优化在桌面端感知不明显但在移动端会因为电池性能和硬件差异被放大别偷懒一开始就写上。4.2 渲染层优化减小 Canvas 状态切换开销Canvas 2D 的绘制是有状态的。频繁切换fillStyle、globalAlpha、transform都会产生额外开销。一条鱼的眼睛、身体、尾巴如果分别设置样式200 条鱼就是 600 次状态切换。优化方式是按样式分组渲染先遍历所有鱼把相同色系的鱼分到同一组每切换一个组才调用一次ctx.fillStyle组内批量绘制更简单的方案是给鱼设计固定的几种颜色模板蓝色系、绿色系、红色系同模板的鱼放在同一批绘制。我实测这种优化让渲染耗时从约 3.5ms 降到了 2.1ms相当于多腾出了 1.4ms 的余量给其他逻辑。4.3 移动端适配触摸、性能、横竖屏移动端适配不是一个功能而是好几个层面的综合工程。我只挑最关键的几点说触摸控制除了拖拽方向还要防止误触屏幕触发浏览器默认行为必须给 Canvas 添加touch-action: noneCSS 属性并调用preventDefault。视口适配如果游戏在 iframe 里嵌入比如网页游戏平台需要用Element.getBoundingClientRect()而不是window.innerWidth来获取实际尺寸因为 iframe 的视口可能不同。降低粒子上限移动端粒子数量减半光斑从 5 个减到 2 个。别小看这些特效那是 GPU 填充率的大户。横竖屏优先锁定横屏竖屏模式下视野太窄大鱼追击小鱼的场景视觉压力大。如果实在要竖屏需要把场景宽度作为动态参数而不是写死横屏的尺寸。4.4 记分系统设计既要爽快又要合理记分公式我做了两个设计原则。一是积分必须跟鱼的面积挂钩因为这才符合物理直觉二是反馈即时可见。积分计算我没有直接用半径的平方而是加了比赛分的权重function getScoreForFish(radius) { const baseScore Math.floor(radius * radius * 0.8); const bonus (radius 45) ? 500 : 0; // 吃掉大型鱼额外奖励 return baseScore bonus; }玩家吃掉一条半径 10px 的小鱼得 80 分但吃掉一条 50px 的巨型鱼能一下子得到 2000 500 2500 分。这种高风险高回报的记分设计能持续给玩家目标感。吃鱼时屏幕右上方弹出的飘字音符我用简单的translate text实现飘字向上移动 30px 然后淡出耗时 1 秒。这部分延迟展示我放在了自绘 UI 层没有用 DOM 元素因为 DOM 在频繁创建销毁时也会引发布局抖动。5. 常见问题与排查技巧实录5.1 碰撞检测漏判或误判现象我明明比他大但撞到身上没反应我明明还没碰到鱼却判定被吞了。排查思路先在渲染层把碰撞圆画出来。在render()的末尾加一行调试代码把每条鱼的包围圆描边显示出来。如果是构成碰撞的圆画出来后发现半径和鱼身不一致基本都是半径定义处没有统一比如绘制时用宽高的一半而碰撞检测用的半径是另一个值。误判通常是半径比阈值太松或者 碰撞发生时同时计算了 AI 之间的互相吞噬导致玩家在附近时 AI 互相吞掉造成了抢怪。修复办法限制 AI 之间发生吞噬的条件比玩家更严格比如 AI 吞噬阈值设为 1.2 倍而不是 1.1 倍。5.2 游戏越玩越慢现象运行 5 分钟后 FPS 下降内存占用逐步上涨。这是对象池没有正确实现或者回收逻辑中的splice操作引起的数组拷贝开销过大。排查方式打开 Chrome DevTools 的 Performance 面板录一段 20 秒的游戏观察内存曲线的锯齿形状。如果曲线一路向上不回落基本可以确定是鱼对象泄露。还有一个隐蔽的原因玩家移动后屏幕边缘不断生成的鱼挤在一起互相不能吞噬导致堆叠鱼数量不受控这种情况要限制同屏鱼的最大数而不是放任。5.3 触摸控制失灵现象手机端点按没反应或者拖动时页面跟着滚动。先检查 CSS 是不是没加touch-action: none。如果加了仍然没反应多半是你监听了mousemove而不是touchmove。桌面端鼠标事件和移动端触摸事件是独立体系必须分别监听并封装成统一接口。最隐蔽的问题是只监听了 Canvas 元素上的事件但 Canvas 被其他 UI 层分数面板覆盖了一部分触摸被面板兜底拦截了。给覆盖层加pointer-events: none或者调整 z-index 可以解决。5.4 Canvas 绘制文字模糊现象UI 分数、提示文字在 Retina 屏幕上发虚。原因是没有处理devicePixelRatio。解决方案见上文 3.1这里再补充一点在ctx.scale(dpr, dpr)之后文字绘制时仍然按 CSS 像素计算但最终经过缩放会清晰。另外ctx.textBaseline middle和textAlign center别漏掉否则文字对齐偏差很容易被误判为模糊。5.5 开源发布时的通用注意事项开源项目发布不是把源码丢到 GitHub 就完事了。你的项目标题带了开源标签那么别人能不能快速跑起来就是第一问题。我建议在README.md里写清楚环境要求现代浏览器即可、运行方式双击 index.html 或者本地起个静态服务器、目录结构说明。有一个实战经验必须分享如果直接用 file:// 协议打开 index.html某些浏览器Chrome会拦截模块加载import 语法会触发 CORS 错误。所以如果你的代码用了 ES Module 或动态加载要么不要用模块语法要么在 README 里明确提示执行npx serve .或python -m http.server。这个坑我见过太多小白卡住了。许可证也要选好。如果你想让大家自由使用但保留署名选 MIT如果希望衍生项目也必须开源选 GPL如果只是学习演示不希望大家拿去商用选 CC BY-NC 系列。这些都不复杂但选错会在后续产生麻烦。开源项目的口碑往往从细节开始积累一个清晰的许可证就是第一印象。5.6 一个隐藏很深的坑粒子爆炸导致性能雪崩我做第一版时犯过一个严重的性能错误每条鱼被吞食时生成 10 个粒子粒子本身也有生命周期。当玩家长大冲到鱼群里疯狂吞噬时一秒钟可能吃掉 10 条鱼粒子数量瞬间冲到 100。这些粒子每个都要独立计算坐标、透明度、大小还要绘制圆形渐变叠加之后帧时间直接翻倍游戏就一顿一顿。解决方案是粒子池化 上限控制。全局同时存在的粒子数量上限为 120超过的部分不生成新粒子而是复用最旧粒子。同时把粒子的绘制从每个粒子单独设置 fillStyle改成所有粒子共用一个半透明白色 全局透明度叠加一条语句完成批量绘制。// 粒子一次性批量绘制 ctx.globalAlpha 0.7; ctx.fillStyle #ffffff; for (let i 0; i particles.length; i) { ctx.beginPath(); ctx.arc(particles[i].x, particles[i].y, particles[i].size, 0, Math.PI * 2); ctx.fill(); }一次fillStyle赋值服务所有粒子性能提升 5 倍不止。这种先聚合再绘制的思想在做任何 Canvas 项目时都值得用到。写在最后的一点建议这个游戏做完到现在我自己玩的时候还偶尔会开一把。说句心里话做这类开源小游戏最值得的不是游戏本身而是你完整经历了一个设计-实现-优化-发布的闭环。你可以在这个基础上加双人模式、加道具系统、加排行榜、加关卡设计每条路都能学到新东西。最后分享一个小技巧发布开源版本之前打开浏览器的 Performance 工具跑一遍游戏看看有没有明显的帧率掉点然后在自己手机上真机打开一次页面用手指实际玩两分钟。很多桌面端发现不了的移动端问题真机一测就暴露无遗。把这些问题都处理干净了再把这版代码放上去。一个干净利落的开源项目远比一个功能堆叠但 bug 一堆的项目更能给你带来口碑。